> 	Do you want to put together a list of projects on which people
> 	could best help?

Sure.  I can even separate them into categories.  Off the top of my
head:

Kernel:

	COMPAT_NETBSD32: This needs a lot more work.  A number of
		system calls either need to be completely
		re-implemented inside this module or they need to be
		modularized so they don't issue copyin()/copyout()s
		and all the parameters can be converted.

	Move up KERNELBASE: KENELBASE is currently 0x00000000f1000000
		even on 64-bit kernels.  We need to either move it
		well into 64-bit land or bite the bullet and
		completely separate the user and kernel address
		spaces.

	Optimized bcopy: I recently coded a bzero/memset that uses
		block load/store instructions.  The same thing needs
		to be done to bcopy/memmove.

	Cleanup locore.s: Locore.s needs a cleanup.  Context switching
		could be improved.

	KGDB: I destroyed the kgdb code and never fixed it back up.

	MP: We need code to probe and attach multiple CPUs.  CPU
		structures need to be added.  The MMU code needs to be
		made MP complient.

	Core dumps: The kernel core dumping code needs to be fixed.

	Booting: The existing bootloader(s) only support booting from
		disk.  Work needs to be done on netbooting and CDROMs.


Driver:

	fas: Enhance the ncr53c9x driver to support the FAS 366 chip
		and create an FAS SBus front end.

	hme: Create a PCI frontend to the HME driver.

	su: We need to take the `com' driver (NS16450/NS16550AF), add
		an `ebus' frontend, and (somehow) hang the Sun
		keyboard and mouse drivers off it.

	se: A driver for the Siemens 82... (um... I need to look up
		the part number) serial chip and front ends for the
		`ebus'.

	ffb: Need to write a driver for this.


Kernel interface:

	libkvm: libkvm needs to be able to read kernel core dumps.

	32/64-bit interoperability: Most of userland does not need to
		be 64-bit.  It's sometimes more efficient to run
		32-bit binaries on a 64-bit kernel, and it would be
		nice to be able to share most of userland between the
		sparc64 and sparc ports.  Other userland utilities,
		such as `ps', use libkvm to grovel through the kernel
		data structures.  We need a cleaner scheme to use both
		32-bit and 64-bit binaries and shared libraries on the
		same machine than the current /eul/netbsd32 method.

	64-bit SVR4: Need to be able to run Solaris 7+ 64-bit
		applications with COMPAT_SVR4.

	32-bit SVR4: Need to be able to run 32-bit Solaris
		applications on a 64-bit kernel using something
		similar to COMPAT_NETBSD32.

Userland:

	X11: We need to fix the X server to support 64-bit SPARC.

	GCC/EGCS: The bugs in the gcc/egcs SPARC V9 code needs to be
		fixed.  64-bit PIC code needs to be fixed.

	Toolchain: We need a single toolchain that can generate
		either/both 32-bit and 64-bit binaries (on both sparc
		and sparc64) rather than the separate ones I'm
		currently using.

	Shared libraries: Once 64-bit PIC code can be generated,
		ld.elf_so needs to support sparc64, and needs to be
		able to interoperate with 32-bit dynamic libraries.

	Sysinst: Somebody want to work on this?

=========================================================================
Eduardo Horvath				eeh@netbsd.org
	"I need to find a pithy new quote." -- me