From owner-freebsd-arch Mon Feb 26 5: 9:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 7DA5E37B401 for ; Mon, 26 Feb 2001 05:09:34 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id GAA20358; Mon, 26 Feb 2001 06:04:24 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAAMuaORN; Mon Feb 26 06:04:15 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id GAA16507; Mon, 26 Feb 2001 06:09:22 -0700 (MST) From: Terry Lambert Message-Id: <200102261309.GAA16507@usr05.primenet.com> Subject: Re: sbufs in userland To: ken@kdm.org (Kenneth D. Merry) Date: Mon, 26 Feb 2001 13:09:17 +0000 (GMT) Cc: arch@FreeBSD.ORG In-Reply-To: <20010226003319.A19994@panzer.kdm.org> from "Kenneth D. Merry" at Feb 26, 2001 12:33:19 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > - 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. Terry Lambert terry@lambert.org --- 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