i spent a couple days last week with the goal of putting
cec into 9load. i need cec because we're out of serial ports
on our perle cards and i need a way to talk to the machines
before 9load has finished.

since 9load had no threads or tasks, it's difficult to manage
bootp and cec concurrently. what i ended up doing was adding
procs/locks and send/recv to 9load. in all, it added about 5k to
the linked 9pxeload; 650 lines of code.

benefits:
1. cec. with "cec -pe $ether" one can connect to a booting server
and interact with the boot menu.

2. the ethernet driver model more closely resembles that of
the kernel. user processes are available and send/recv are used
instead of the RingBuf structure. ethernet drivers should be
easier to port. i did a port of a new driver from the cpu kernel
in about 20 minutes. most of that time was spent deleting code,
but unfortunately there was a good bit of time spent dealing with
slightly differnt names or calling conventions. the driver didn't
need any restructuring even though it uses kprocs.

one thing i'm considering for the future is having the kernel
panic or halt back to 9load rather than rebooting the box.
(like a virtual rom monitor.) then 9load could provide a debugging
interface to deceased kernels (or rather the hooks for a remote
debugger to use). this would require working out a way for
9load and the kernel to stay out of each other's way, but i don't
think this would be too hard.

cavet emptor: although i modified all the ethernet drivers, only
82563 and 8169 are tested.

the source is in /n/sources/contrib/quanstro/9boot.

- erik