I feel a little bit funny arguing against putting something in the
kernel when you're arguing for it, Chris.   However, since you bring
it up, ...

> This means that any diskless system using DHCP will have to waste a
> "fair chunk" of memory (where "fair chunk" could very well be most of
> or more than a MB, depending on the system type), permanently, to deal
> with system startup.

No, you unmount the memory disk when you're done.   Or don't make it a
memory disk - just have a hunk of initialized data in its own section
that contains the executable, and free() it when you're done.

> (1) you're mounting another (network) partition over your real root.
> (Is that even possible (i forget)?  certainly it has the possibility
> for interesting interactions with 'df' and users' expectations.)

A SMOP.

> (2) It makes rebuilding your kernel much more complex (no more simple
> rebuild/reboot, you now need to build the kernel and stuff a ramdisk
> image in it, etc.

It adds one step.  There is no etc - you just need to stuff the
ramdisk image.  Big deal.  It makes life a lot easier.

> (3) You now have hidden binaries.  What if your dhclient dies, or you
> want to restart it for whatever reason?  You no longer can be even
> remotely sure that the binary that was running is the binary in the
> 'normal' place on your file system.

Sure you can.  If you're turning kernels around frequently because
you're debugging, you have to be careful.  If you're running -current,
and updating frequently, you probably ought to be careful.  If you're
running NetBSD out of the box, you should be fine - you'd really have
to work to screw yourself.

> I know very little about DHCP, but from what i've heard, a chunk of it
> _has_ to go in the kernel anyway.  You need to do lease management (at
> least expiration) in the kernel, because if you don't you could
> potentially end up using an IP address after your lease has run out
> (what if your daemon dies).

You need lease expiration in the kernel.  That's all.   As Jason has
pointed out, this is equivalent to expiring addresses in the ARP
table.   I doubt it would add even 1k of code size to the kernel.   On
the other hand, here's my DHCP client:

	text    data    bss     dec     hex
	57344   12288   41900   111532  1b3ac

This includes code to manage the persistent lease cache, which you
want to keep around in case you reboot while the server is down.
Granted, this isn't needed on diskless clients, but it's certainly
valuable for diskful clients.   It includes code to assemble and
disassemble DHCP packets, which is more complicated than you might
think because of the way the DHCP protocol piggybacks on the BOOTP
protocol.   It includes code to parse a configuration file, and to
emit human-readable (and thus, shell script-readable) definitions of
DHCP options.

I could probably build a stupid DHCP client that would do the absolute
minimum required to get a kernel running, and fit it in less than 10k.
I could spend a couple of weeks trying to get it working reliably in
the kernel.  But you'd still want to run the real dhclient in
userland, to get the full functionality.  So why waste 10k of
wired-down kernel space?

			       _MelloN_