Date: Mon, 1 Apr 1996 13:58:47 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: wollman@lcs.mit.edu (Garrett Wollman) Cc: terry@lambert.org, freebsd-current@FreeBSD.org Subject: Re: We need to do another XFree86 release for -current someday soon.. Message-ID: <199604012058.NAA14351@phaeton.artisoft.com> In-Reply-To: <9604011511.AA29614@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Apr 1, 96 10:11:32 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > I think the stubs should go in and the version bump can wait for the > > parameterization, > > It's TOO BLOODY LATE! Shared library version numbers are an > INCREASING function with respect to time. With respect to release times, yes. > > which should make the library not care about the > > underlying transport code > > The library doesn't give a damn about the underlying transport code > (as would have been obvious to you if you actually used the code > rather than wasting my time whining about its removal). The library > routine iso_ntoa() requires header files defining the structure of a > CLNP address and `struct sockaddr_iso'. Those header files no longer > exist. Therefore, the code will no longer compile. Period. End of > story. Well, for fear you were right as you usually are, I went and looked. You weren't. Allow me to explain. The library cares, because it attributes ntoa by protocol family in the symbol name space. This is, to be entirely too blunt, fucked up. It should use something like: #define inet_ntoa( in_addrp) ntoa( AF_INET, in_addrp) ... #define iso_ntoa( iso_addrp) ntoa( AF_ISO, iso_addrp) ... etc. Which is to say, the library interface should be invariant over the death/birth of protocols. Ie: no version number changes when a protocol is no longer supportedi, no version number changes when a new protocol becomes supported. The #define is for legacy code, and goes in the appropriate protocol-specific header. To get to the protocol specific pieces, it would ideally dlopen protocol specific function vectors for such routines, and these would be located in libexec, and there would be a registration list that was consulted to find them (or they would exist in a directory by them selves so that all entries in the directory could be iterated). Barring that, the code should be associated with the protocol module in the kernel and the operation completed as an ioctl() on /dev/net or something similar, which in the absence of dlopen in user space, as is proper, could provide a kludge soloution using the LKM init procedure to hook family specific callbacks. Even if a parameter were to be invalidated, for instance, AF_ISO, and the interface was still parametric, this would result in automatic an implicit stubbing of the affected routines -- which would, again, not require a major version number bump, since it would not constitute an interface change. Obviously, to put any of this in place to avoid similar future problems requires a major version number bump. What we are arguing is whether the ultimate coloution can be included in the forthcoming release. If not, unless there is sufficient other changes to require the bump, the change should be delayed. One incorrect soloution (a partial namespace fix) is no worse than another (function stubs in place of a partial fix). Attribution of protocol family in the symbol space is insufficiently dynamic and should not be tolerated. This is the parameterization, as previously discussed. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604012058.NAA14351>