> - Put sbufs in some existing library, or in a specially
> created library, i.e. "libsbuf" or something like that.
This makes the most sense, to me. It should even be possible
to link the kernel against the same code. The library could
be built out of the kernel sources by reference (there are a
number of libraries that use sources from other places/tools
as part of their build).
> - Put sbufs in libc.
Don't do this.
> This has the distinct disadvantage of likely being
> contraversial, and would perhaps violate some standard or
> other for libc interfaces.
Yes; in particular, given the recent discussion on the GCC
branding problems for determining ABI type for statically
linked binaries, part of the referenced mailbox file contents
specifically talked about using one platform's libc with a
binary built on a different platform.
This rather ignores the ld.so selection issue, but if you can
get over that hump, it's clear that SGI, SCO, Intel, and so
on expect this to work with IA64 binaries on their platforms
and Linux (it seems to me that this is a bad tactic, but I'll
leave that discussion for elsewhere).
That pretty much means standardizing library names and entry
points for anything moderately complex to sucessfully run
with local libraries.
I rather expect FreeBSD will find itself forced to update the
resolver code, and break it out of libc into a libresolv, like
everyone else, since otherwise network-using programs will not
work. It probably also means the socket code will have to
ignore uninitialized data fields in sockets, rather than barfing,
since that works on other platforms, and it's a common portability
problem with network using programs, when going to FreeBSD.
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message