Matthew Dillon wrote:
I've cleaned up most of the conflicts that would otherwise prevent
kernel code from being linked against libc. There are only a few
remaining and really only one that entails a great deal of work...
that being the kernel's malloc(), realloc(), and free() procedures.
Matt, I really think this is no good idea. I don't understand why you are trying to link the kernel with libc in the first place anyways. The real 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 driver, 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 more easy and elegant with a linker script. Unfortunately I was out of the loop when this discussion started, so I realize a big share of renaming has already happened (which I couldn't look at up till now, because it seems your network is unavailable). But this change isn't in place yet, and I strongly oppose it. I'm not arguing against a usermode kernel, yet I think that linking it with libc is not the right idea. A kernel is self-contained anways, and the interfacing with the surrounding is done by drivers, so I don't see why this should be different for a usermode kernel. Additionally, I think that having a usermode kernel and Xen support don't exclude each other. cheers simon -- 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 / \
signature.asc
Description: OpenPGP digital signature
