From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <7ab29a80f86a33032131fbd83a0b1e97@quanstro.net> From: erik quanstrom Date: Tue, 18 Dec 2007 19:53:43 -0500 To: 9fans@cse.psu.edu MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: [9fans] 9load Topicbox-Message-UUID: 1c7bb77a-ead3-11e9-9d60-3106f5b1d025 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