>1. Put only stuff in there that's in user level libraries, too. Things that
>only depend on the cpu architecture, but not on the machine. Probably someone
>else should argue in favor of this.

i'm heavily in favor of this. in the future i expect that we might
find it nice to link secondary boot programs against libsa as well
as libkern. libkern is a nice minimal libc.

>2. Put in there any kernel stuff that's not configuration dependent. That is,
>things that don't depend on any options/devices/pseudo-devices or the like.
>Things that you cannot easily tell whether they belong in a specific kernel
>or not.

how long before tty.c ends up in libkern? (cringe).

>This requires however some definition how we will resolve issues like where
>to put stuff that isn't necessary in all kernels (like e.g. the routines
>now in disklib.c). I don't like it to be defined standard.

because of the LKM problem i am well along the way to being convinced
that libkern should actually be a .o file instead of .a file.

i'd prefer libkern to stay very very clean, particularily to link
against boot stage loaders later on.

------------------------------------------------------------------------------