Subject: Re: libkern compile on hp300
To: None <netbsd-bugs@sun-lamp.cs.berkeley.edu, tech-ports@sun-lamp.cs.berkeley.edu>
From: Wolfgang Solfrank <ws@tools.de>
List: netbsd-bugs
Date: 03/11/1994 20:12:56
Probably a discussion of what should go into likern is in order here.

These seem to be the possibilities (well, the extremes?):

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.

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.

As you can guess from the above, I'm inclined to the latter solution, but
I might be persuaded for the former.

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.

In addition there are routines that could serve as a sample implementation of
things when porting to a new architecture is started, and then later replaced
by probably faster machine dependent routines (e.g. in_cksum, or suword).
Currently you have to get these right from the start (more or less)
yourself, as the code is pretty machine dependent for existing ports.
Providing C-coded versions for some stuff would make porting easier, wouldn't
it? In fact, the i386 port still does not have a correct suword, suiword,
susword and addupc.

Comments?
--
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) +49-228-985800

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