Date: Sat, 18 Mar 1995 19:00:47 +1000 From: Bruce Evans <bde@zeta.org.au> To: davidg@Root.COM, rgrimes@gndrsh.aac.dev.com Cc: CVS-commiters@freefall.cdrom.com, cvs-sys@freefall.cdrom.com Subject: Re: cvs commit: src/sys/libkern locc.c random.c scanc.c skpc.c libkern.h Message-ID: <199503180900.TAA13851@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
> It's bad enough that we have a libkern in the first place, and it's a lot >worse that it has all of these contortions. I personally prefer to know >exactly what is going to be in the kernel and find it more than a little >obnoxious to have an unknown set of .o's included out of libkern.a, and quite >evil for the sources to come out of libc. I'm willing to live with the pot-luck >.o's, but I'm not willing to live with them coming from libc. How about compiling them and putting them in a library in each kernel directory? The library is just to avoid putting unused objects in the kernel (linux puts all the kernel objects in libraries). I think the sources should come from libc if there is an adequate version in libc (this is true for str*, quad, and perhaps for mem* (the library bcopy and bzero are optimized for different usage). Very few ifdefs should be necessary. lkm's may cause complications. What happens if an lkm needs a routine that is in libkern but not in the kernel? I think it doesn't work. lkm's aren't linked to libkern now, and libkern will be harder to find if it is not in a central place. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503180900.TAA13851>