> It seems the correct thing to do here is to put the shared part in libc,
> list the file in KSRCS in lib/libc/Makefile.inc, and make copy-to-libkern.
> This allows for only one copy to need to be maintained, and avoids hard
> build-time dependency tentacles between lib/ and sys/.
> (If this is not correct, let me know what's better.)
>
> Unfortunately, libc and libkern haven't been kept in sync for many years
> and I don't see a technical reason why not, so lets bring them together?
That's a slippery slope you're walking on.
>From a theoretical point of view, the routines common to libc and
libkern should be identical.
>From a practical point of view, this is not always the case. I'll only
cite the two most important reasons:
1. libc is a library, and is required to provide entry points for all
its interfaces (such as htonl), so that their address may be used for
function pointers, even if the function itself is a no-op or would
better be an inline; libkern has no such constraints.
2. libc is intended to run in userland, and libkern, well, in the
kernel; running in the kernel might require different code constructs
and/or will allow for privileged instructions to be used (especially
if address spaces are kept completely separate between kernel space
and user space)
> First, str{cat,cpy} were vehemently expunged from the kernel many years ago,
> so stop trying to keep them around.
>
> Index: lib/libc/Makefile.inc
Hello, this is libc you are butchering in. I'm afraid strcat and strcpy
are still required to be in libc by the current C and POSIX standards.
> Next, __P is dead. Theo just removed the mention of it from style(9), and
> this happens to be the last one in libc. It was removed from the libkern
> copy 9 years ago, but that change never made it "upstream" to libc.
>
> Index: lib/libc/quad/qdivrem.c
This one I agree with.
> bcmp(3) was cleaned up in libc, but that never propogated to libkern.
> While here, remove a comment that doesn't belong in the MI version.
>
> This does change the functionality a bit, but anything relying on undefined
> behavior or specific value of "non-zero" here is fundamentally broken, and
> I didn't see anything making such assumptions on a quick grep through sys/.
>
> Index: sys/lib/libkern/bcmp.c
This one brings bad memories, as memcmp() in the kernel used to map to
bcmp() on vax, and this broke red-black trees. But having libkern here
match libc (at least on the platforms where the kernel bcmp() is
provided by this file) will not hurt.
> {h,n}to{n,h}{l,s} and bswap32 have been broken up into different files in
> libc,
> but I'm not sure how to properly break that up into MI/MD components for
> libkern
> and include it in the right places without breaking anything, does somebody
> else
> want to take a look?
See comment about different rules between libc and libkern. Kernels for
platforms with the right byte order need not actually contain these
symbols.
> Also, for future reference, would these patches be preferred in separate
> emails?
Preferrably (and lines trimmed to the usual 72 columns). Although for
simple diffs, this may be acceptable.
