[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: References made in chapter one....

On Wed, 14 Mar 2001 tytso@mit.edu wrote:

> While adding a normative statement reference in chapter one for
> specifications, I noticed the section on "related implementations" where
> mention is made of the following:
> * BSD	BSD 4.4 Lite version 2 (no URL)
> 	We really should get a URL for this.... anyone know of a stable
> 	one off-hand.  Also, these functions should probably get
> 	documented first when we start the LSB 1.1 effort, since I'm
> 	concerned about "code drift"; it's been a long time since BSD
> 	4.4 Lite, and the library interfaces may have changed in subtle
> 	ways since then.


> * GNU/Linux defacto standard	http://www.gnu.org/
> 	This is a bit too broad; if we mean "glibc" or "bash" we should
> 	say so, and then specify exaclty which version we mean.
> 	I'd also just as soon avoid the whole GNU/Linux vs. Linux
> 	religious argument if at all possible.  Note that as far as I
> 	can tell although baselib/libc lists "GNU/Linux defacto
> 	standard", none of the symbols actually reference the footnote
> 	number corresponding to it, at least on the verison that's
> 	currently up at www.linuxbase.org.  The only place that
> 	referenes this is setresgid/setresuid in the usergroups
> 	section. 

This is intentional. It is all of these things that we have to document
in the LSB itself since there often isn't a real specification to back
these up. Stuff covered by POSIX, SUS, et al is attributed to that standard
so only left-over stuff would be attributed to this reference implementation.

> * RPC & XDR	RFC 1831 & 1832		http://www.ietf.org
> 	This reference is certainly wrong, since it's not an API
> 	reference and never pretended to be.  We should probably
> 	reference the comp.source.misc Sun posting of SunRPC, or just
> 	simply reference a specific glibc version for now, since that's
> 	what we're actually using.  

I've been asking for 2 years for an API description 8-), but no one seems
to have one. If we follow our rules strictly, we should yank all RPC related
interfaces because of this.


Stuart R. Anderson                               anderson@metrolink.com

Metro Link Incorporated                          South Carolina Office
5807 North Andrews Way                           129 Secret Cove Drive
Fort Lauderdale, Florida 33309                   Lexington, SC 29072
voice: 954.660.2500                              voice: 803.951.3630
http://www.metrolink.com/                        XFree86 Core Team
Creative Applications Lab Chair - SIGGRAPH 2001

Reply to: