Date: Thu, 11 Sep 2003 00:49:58 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: drhodus@catpa.com Cc: chat@freebsd.org Subject: Re: strip FreeBSD a bit Message-ID: <3F602926.E81D0CAD@mindspring.com> References: <3F50C956.70603@carebears.mine.nu> <20030830151544.G21642@znfgre.qbhto.arg> <3F5193E2.8060805@carebears.mine.nu> <20030831065010.GA23179@titan.klemm.apsfilter.org> <20030909221106.GA31532@dds.nl><xzp7k4g26lc.fsf@dwp.des.no> <3F601E8F.D67D79F5@mindspring.com> <1063264693.3f6021b5527e8@www.catpa.com>
next in thread | previous in thread | raw e-mail | index | archive | help
drhodus@catpa.com wrote: > > FYI, UUCP is also required by POSIX 1003.1-2003 > > > > http://www.opengroup.org/onlinepubs/007904975/utilities/uucp.html > > > > It's part of the [XSI] subset, which is required for compliance > > with the Single UNIX Specification. If FreeBSD wants certification > > someday, it will have to bring back UUCP. > > Perhaps this only shows that the POSIX standards should not be > looked at anymore and a new standards group is needed..... I'll be happy to switch, as soon as you form your new standards group, get it accepted internationally by international standards bodies, and then get your standard on the GSA schedule as being an allowable product purchase in lieu of POSIX when bidding on government contracts. 8-) 8-). When you do this, perhaps we can rip the assinine System V signal non-restart behaviour, System V instead of BSD tty dissociation code that makes us have to check return codes on reads after a tty is revoked rather than just taking a SIGHUP from our parent, and System V behaviour when closing one of several open instances of a file, when there are advisory locks outstanding on a descriptor other than the one you are closing. Doing this would *vastly* simplify our threads libraries, FWIW, and cut by 300% the number of real system calls per wrappered call that needed to be made *each and every wrappered call* in libc_r (hint: mask_signals/call/unmask_signals). At the same time, maybe we could fix the fact that multiple fd's open on the same file, and resulting from fork/fcntl(,F_DUP)/dup/dup2 all share the same structure, so that if one process modifies the file offset, all of the others end up getting the modified offset, instead of their own offset. BTW, all this cruft and more were concessions to POSIX conformance, vs. The Traditional BSD Way Of Doing Things. Maybe we could make people use mmap() and rendezvous via a file, in order to obtain shared memory, instead of wiring down kernel maps and using up precious kernel resources with shmget/shmat, while we're at it. Typing up all the cruft that came in with the tacit requirement for POSIX conformance would be enough to make even my fingers tired... but I recognize the need for standards conformance, so if all you have is an ugly standard, well, it's better than no standard at all, or a mythical not-yet-standard standard. -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F602926.E81D0CAD>