Annotation of wikisrc/projects/ideas.mdwn, revision 1.6

1.1       jmmv        1: [[!meta title="Brainstorming of project proposals"]]
                      3: This page includes a brainstorming of ideas for project proposals.  While most,
                      4: if not all, of the projects in this page are good ideas to propose to
                      5: potential applicants, the ideas themselves have not received enough attention
                      6: to write up a project specification for them.  Any project considered good
                      7: enough to be thrown at applicants should get a page of its own within
                      8: projects/project/* and get a well-defined write-up explaining what the project
                      9: is about, why it is important for NetBSD, and what is expected from the
                     10: applicant.
                     12: [[!toc startlevel=2]]
                     14: # Kernel Projects
                     16: 1. related to (2) - rewrite sysctl to be less difficult to use
                     18: 1. Implement SYN cookies, stretch goal - extended syn cookies with timestamp usage
                     20: 1. *difficult* a QoS implementation for NetBSD in the year 2011
                     22: 1. Debug, and merge the iscsi initiator - stretch goal - get rid of the weird portal stuff which we don't need
                     24: 1. update linux emulation 
                     25: >> Update to what it was updated not long time ago to 2.6.18 kernel.<br>
                     26: > Indeed, and RHEL 5 uses a modified 2.6.18 kernel. But RHEL 5 has been available since March 15, 2007, and is due to be "End of Production 1" in Q4 2011 -- agc
                     28: 1. *difficult* investigate ffs dir hashing, and fix related bugs (hard)                    
                     29: >> I implemented a debugged generic dir hashing. It could be extended to also allow FFS, but FFS's directory stuff is all over the place and i fear to break it. Also FFS directory packing needs attention. -- Reinoud
                     31: 1. *difficult* single instance storage and de-duplicating (might be too long?)
                     32: >> This might be possible to implement on top of device-mapper driver.<br>
                     33: > I was thinking that Single Instance Storage and de-duplication really needs access to userspace, and is best implemented there  -- agc
                     35: 1. *difficult* get some form of jails up and running                                       
                     36: >> Maybe restoring MULT to working state is an option here, another possibility is to get gaols working. Some fresh approach to jails might be implemented on RUMP because it basically allow us to create in process virtual machine and run them independently.
                     38: 1. add shred/wiping and memtest options to boot menu
                     40: 1.  add ability to store entropy at shutdown time, and to boot and restore same entropy.  at same time, add a monitor (chi^2?) for randomness over small sample sizes to /dev/random.  investigate other ways of generating pseudo random numbers - 2 mersenne twisters sampling at different speeds, and throwing away random interim values due to another re-keyed prng or better.  i.e. beef up our random number generation.
                     42: 1. find a method to boot a boot.cfg entry once (and then fall back to the default method). This requires, especially, that the boot flip back to the default method if the once-off fails.
                     44: 1. *difficult* Write new DTrace provider for watching locks(lockdebug), userspace or any other from available ones <>
                     46: 1. Change keyboard drivers to emit USB scancodes in event mode so for example ADB or Sun keyboards can coexist with things like USB keypads on the same mux and we don't need a separate InputDevice section in xorg.conf for each. This should be relatively easy.
                     48: 1. Port FreeBSD's DAHDI implementation to NetBSD, so that Asterisk on NetBSD will have hardware support.  FreeBSD's DAHDI implementation is SMP, so this isn't a simple port.  Also, just about every FreeBSD kernel API related to device drivers and modules are different from the NetBSD equivalent meaning that one needs to basically know both kernels.
                     50: 1. Merge all PC style floppy drivers to be similar to other "portable" drivers that use a bus frontend with a common chip backend (or possibly two:  pseudo DMA and real DMA).
                     52: 1. Create a new HID framework so that we can merge the USB and Bluetooth HID drivers, also allowing creation of drivers to properly handle devices such as Apple Magic Mouse which use several [undeclared] reports.
                     54: 1. Improve tmpfs
1.3       wiki       56: 1. Update zfs pool to version 5000.
1.4       wiki       58: 1. Add MI interface for IEEE 802.3 Clause 45 MDIO access.
                     60: 1. IEEE 802.3az(Energy Efficiency Ethernet(EEE)) support.
                     62: 1. Add Support dot3 MIB.
1.1       jmmv       65: # Userspace Projects
                     67: 1. a Java implementation we can use across all netbsd platforms
                     69: 1.  (controversial) a pcap-based port-knocking system, similar to pkgsrc/net/knock
                     71: 1. puffs-based cvsfs (there's one out there which relies on extattrs)
                     73: 1. fuse lowlevel
                     74: >> Wasn't this already done ?<br>
                     75: > ReFUSE does the upper layer of FUSE, and the excellent /dev/fuse does the device interface, but we are still lacking FUSE lowlevel functionality -- agc
                     77: 1. automatic setlist generation - see my post to tech-userlevel a few months ago for the code i used (and which was used to generate all the libisns entries, btw).
                     79: 1. Embedded World-Generator: a tool to build smaller distribution and using custom packages and software - aimed at the embedded market                                         
                     81: 1. Device-mapper RUMP testing: Write device-mapper  testing framework based on libdm and RUMP this should be able to allow us to develop new targets easily.
                     83: 1. RUMP ZFS testing: integrate and write ZFS testsuite for NetBSD.
                     85: 1. Update userspace build of ddb (/sbin/crash) add more architectures and more functions to live/post mortem kernel debugging.
                     87: 1. A new puffs(4) based auto-mount daemon which supports direct mounting (not via "/amd") and Solaris style auto-mounter maps.
                     89: 1. port valgrind to NetBSD - [valgrind]( is a code instrumentation framework that can be used to find memory related bugs in programs as well as conduct performance analysis. Valgrind is written for linux, and recently there is has been a MacOS/X port. The code is very much linux specific, and we should talk to the maintainers before starting work on it to find out if they will accept a NetBSD port, and also provide some assistance with the design of a portability layer. We should also do some research to see if we can re-use the [FreeBSD]( port.  For previous attempt see
                     91: 1. Implement enough of libudev so that Gnome (KDE?) in pkgsrc can use it
1.2       wiki       93: 1. Stack Backtrace Library - Write a library that the kernel debugger and return_address(9) can use to walk down the call stack.  Use the technique that [David Laight]( recommends: TBD.
1.1       jmmv       94: 
1.4       wiki       95: 1. Daily autotest system for ARM
1.1       jmmv       97: # pkgsrc projects
                     99: 1. Modular libtool: rewrite libtool replacement that is faster and more convenient to maintain, so that one can add compilers to it without rebuilding the whole package.
                    101: 1. Go back to previous pkgsrc install state: Write a tool to help with reverting the installation to some previous state. See pkg_tarup, pkg_chk.
                    103: 1. Add support for multi-packages (building multiple binary packages from single source).
                    104: > don't we do that already? (I guess this means: more info please :-) -- spz
                    105: >> No, we don't. We don't produce more than one package during the single build.
1.3       wiki      106: 
                    107: 1. Running VirtualBox on NetBSD as a host.

CVSweb for NetBSD wikisrc <> software: FreeBSD-CVSweb