|From:||"Simon 'corecode' Schubert" <corecode@xxxxxxxxxxxx>|
|Date:||Tue, 05 Sep 2006 20:07:31 +0200|
:Matt, I really think this is no good idea. I don't understand why you ar= :e trying to link the kernel with libc in the first place anyways. The re= :al kernel doesn't need libc, so why should the userland kernel need it? = :What I see what's needed are three usermode kernel drivers: a console dr= :iver, a usermode network interface driver and a signal handler. I don't = :see anywhere that libc is really needed. : :Additionally, renaming malloc et all in the whole kernel just seems a big= :, possibly even error-prone change, where it can be accomplished much mor= :e easy and elegant with a linker script.
I thought it might be a bigger job then it actually was. It turned out to be trivial. Sure there are going to be a few hicups, but nothing that I would consider a big deal.
Well, if we don't link it against libc then developing pseudo devices that interact with the real system would require considerably more infrastructure. I kinda prefer having libc around so I can just write that code as I would any application.
Lets consider the types of devices we want to support in the virtual kernel. These devices must communicate with the real world:
* Console - Just use stdin and stdout
* 'External' Serial ports - Just use a couple of the real kernel's PTYs
* Disk - open/lseek/read/write/close
* Memory - mmap( ... MAP_ANON)
* Network - Just use the real kernel's TUN interfaces.
It would even be possible to using the new
bridging code to put a virtual kernel directly
on the real system's LAN.
Writing those devices should be a matter of a day or two on each one
with libc available. It will be so easy that I'm not even concerned
-- Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
Description: OpenPGP digital signature