> I'm not sure I understand this.. Is there such a thing as a 'kernel
> interface', i.e. a list of kernel library functions that should be
> used?

Yes.  Do you use open() in the kernel?  Do you use fprintf() in the
kernel?  (I've seen people try both, and worse...)

No you don't.  Programmers don't often think about it, but there _is_
a set of things that you do very differently in the kernel than in
user land.

One example in the NetBSD tree is b*() vs. mem*() -- mem*() are the
POSIX interfaces, and are the 'right' things to use in user-land code,
but the b*() interfaces are what have been used in the kernel forever
and, last i heard, there was no great desire to change that.

Two more examples are malloc() and free()...  Thankfully, now that
prototypes exist just about everyplace in the kernel, bozos can't call
malloc() and free() with their user-land args.

Frankly, people who don't understand that there are certain functions
that you should use in the kernel and that there are certain functions
that you shouldn't use are no _end_ of trouble, especially in
environments like the one that i work in (where we end up with some
... interesting short-term student employees).


> And, secondly, suppose there are >= 2 places in the kernel
> where you need to initialize a bit of memory with a certain byte value,
> are you saying that one should, even then, not define memset()?

Yes, unless you want to make it part of the interface that everything
in the kernel should use.

I have no objection to memset being added, but if it is, then bzero()
should be considered deprecated, and code should be converted to use
memset().  There's no point in having two interfaces to do (almost)
the same thing, and the kernel is small and cohesive enough that
somebody _should_ go through and change all instances, if this
decision is made.

Say i wrote a 20,000 line program, and used bzero() 50% of the time
and memset() the other half...  That's certainly not optimal, for more
than one reason.


cgd