This page includes a brainstorming of ideas for project proposals. While most, if not all, of the projects in this page are good ideas to propose to potential applicants, the ideas themselves have not received enough attention to write up a project specification for them. Any project considered good enough to be thrown at applicants should get a page of its own within projects/project/* and get a well-defined write-up explaining what the project is about, why it is important for NetBSD, and what is expected from the applicant.
related to (2) - rewrite sysctl to be less difficult to use
Implement SYN cookies, stretch goal - extended syn cookies with timestamp usage
difficult a QoS implementation for NetBSD in the year 2011
Debug, and merge the iscsi initiator - stretch goal - get rid of the weird portal stuff which we don't need
update linux emulation
Update to what it was updated not long time ago to 2.6.18 kernel.
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
difficult investigate ffs dir hashing, and fix related bugs (hard)
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
difficult single instance storage and de-duplicating (might be too long?)
This might be possible to implement on top of device-mapper driver.
I was thinking that Single Instance Storage and de-duplication really needs access to userspace, and is best implemented there -- agc
difficult get some form of jails up and running
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.
add shred/wiping and memtest options to boot menu
add ability to store entropy at shutdown time, and to boot and restore same entropy. at same time, add a monitor (chi2?) 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.
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.
difficult Write new DTrace provider for watching locks(lockdebug), userspace or any other from available ones http://wikis.sun.com/display/DTrace/Providers
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.
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.
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).
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.
a Java implementation we can use across all netbsd platforms
(controversial) a pcap-based port-knocking system, similar to pkgsrc/net/knock
puffs-based cvsfs (there's one out there which relies on extattrs)
Wasn't this already done ?
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
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).
Embedded World-Generator: a tool to build smaller distribution and using custom packages and software - aimed at the embedded market
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.
RUMP ZFS testing: integrate and write ZFS testsuite for NetBSD.
Update userspace build of ddb (/sbin/crash) add more architectures and more functions to live/post mortem kernel debugging.
A new puffs(4) based auto-mount daemon which supports direct mounting (not via "/amd") and Solaris style auto-mounter maps.
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 http://vg4nbsd.berlios.de/
Implement enough of libudev so that Gnome (KDE?) in pkgsrc can use it
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.
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.
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.
Add support for multi-packages (building multiple binary packages from single source).
don't we do that already? (I guess this means: more info please :-) -- spz
No, we don't. We don't produce more than one package during the single build.