Date: Mon, 13 Jan 1997 16:19:33 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: adonai@jump.net (Lee Crites) Cc: freebsd-hackers@freebsd.org, dg@root.com, wollman@lcs.mit.edu Subject: Re: bug in setsockopt()... ? Message-ID: <199701132319.QAA28617@phaeton.artisoft.com> In-Reply-To: <1.5.4.32.19970113213527.00685734@jump.net> from "Lee Crites" at Jan 13, 97 03:35:27 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> So now, back to my originally stated requests: > > * Can anyone point me to a list of the bugs in the ipc functions? There are some documented for various mechanisms, in the corresponding code itself. Other than that, there is mostly here-say. > * Who are the people working on them? In general, anyone who submits patches. It's somewhat of a "whoever touched it last". A lot of recent work went into the shared memory stuff (several months ago), for instance. The need to use msync() in INN was one of the things that came out of that. > * What kind of help do they need? The biggest help would be a validation suite. It would attempt all iterations of usage for an IPC facility, and report discrepancies between actual and expected behaviour. Expectation should be in terms of POSIX, SVID, and the Single UNIX standards, primarily, and historical behaviour, secondarily. There is a rather thorough validation suite for shared memory, which you can find in the -current list archives (it was posted to -current some time ago). I believe that it *does not* include interaction of a mmap'ed object with the file I/O subsystem; currently, the only test that shows the INN failure to use msync() appropriately is INN itself. 8-(. > * Can I try to abuse some of the fixes? Better to establish a baseline; without knowing expected behaviour, it will be difficult to establish the net effects of any fix. A "fix" which fixes one expected behaviour, but breaks three others, for instance, can not be easily identified without an exhaustive suite for testing behaviour before and after the fix. > And, some further, while I admit only implied, requests: > > * Is there a cental point with a list of the currently identified bugs? Yes. The gnats bug tracking database on freefall. This is accessable via www.freebsd.org; look there fore more details. > * How does somone with a vested interest in them get to that list? It is publically accessable. You should start with "man send-pr". > * How can someone like me help out? Fix all the bugs in the database. 8-). > * Are there compatibility tests with other os's? Yes. THe NIST/PCTS was recently fully released (see the NIST www page for details). The NIST/PCTS is the "National Institute of Standards and Technology, POSIX Conformance Test Suite". Apart from this, there is the Single UNIX Standard, from X/Open, the POSIX validation suite, also from X/Open, and the SVID/CTS (System V Interface Definition Conformance Test Suite), from USL. > If so, how can I see the results? For the NIST/PCTS, you must download it, and fix FreeBSD so it runs (by definition, it will not run in a non-conformant environment. The patches for this were uploaded to freefall, and posted about on -current; they are pretty much trivial. For the others, you will need to come up with $80,000 or more apiece for the various vendors. Not really worth it. > If not, why not? See above. > Are you waiting for someone to make it? There has been some discusion about the usefulness of standards; in particular, if you can;t flip a switch so that while you are developing or testing applications, that *ONLY* the ABI facilities that are part of a standard are usable, and all others return an error, then you can't really expect the standard to be useful. There was some discussion, on the BSD and Linux lists, and also on usenet, about starting a project "FABIO": Free Application Binary Interface Objective. The purpose of this would be to be able to switch a system into "FABIO mode" for vendor validation of applications. All applications passing this validation would be guaranteed to operate on all "FABIO compliant" systems. Compliance would be by way of self certification using a validation suite (again: we need a better set of validation tools). The FABIO ABI definition would start by picking one or more commercial systems and declaring them "runtime compliant" -- that is, they would not be good developement systems because you could not turn off vendor-private OS features during the application developement/validation process to ensure your app would run on all FABIO systems instead of just that vendors. The rest of the FABIO compliant systems (basically, free UNIX clones and any commercial vendor who wanted to jump in) would be "developement compliant". The net effect of this, if Linux and all the BSD's were on board, would be to move the commercial developement of binaries off to "developement compliant" systems, since by doing so, developers could have one package that would run on the largest number of machines. It would also mean that free UNIX clones that were FABIO compliant would not be orphaned -- commercial products would be much more widely available. Currently this is no more than it's name: an Objective, not an accomplished fact. What's missing is a target commercial system declaration (preferrably including version number) and ELF support in the default FreeBSD tool chain. > If it was made, would the results be appreciated or scorned? It would probably be appreciated, but only if it went far enough that it had value other than to maintaining an existing customer base for FreeBSD alone (which a FreeBSD specific validation suite for IPC facilities could do, but would do little beyond that. > There are more, but I think that give a clearer picture of where I wanted > this discussion to go... Well, hopefully, this is an answer you can accept. 8-). 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?199701132319.QAA28617>