From owner-cvs-sys  Sat Mar 18 01:06:10 1995
Return-Path: cvs-sys-owner
Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA24812 for cvs-sys-outgoing; Sat, 18 Mar 1995 01:06:10 -0800
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id BAA24796; Sat, 18 Mar 1995 01:05:43 -0800
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id TAA13851; Sat, 18 Mar 1995 19:00:47 +1000
Date: Sat, 18 Mar 1995 19:00:47 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199503180900.TAA13851@godzilla.zeta.org.au>
To: davidg@Root.COM, rgrimes@gndrsh.aac.dev.com
Subject: Re: cvs commit: src/sys/libkern locc.c random.c scanc.c skpc.c libkern.h
Cc: CVS-commiters@freefall.cdrom.com, cvs-sys@freefall.cdrom.com
Sender: cvs-sys-owner@freebsd.org
Precedence: bulk

>   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