Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!spool.mu.edu!uunet!mcsun!sun4nl!eur.nl!pk From: pk@cs.few.eur.nl (Paul Kranenburg) Subject: Re: File Truncation Philosophy Message-ID: <1993Apr14.085800.17960@cs.few.eur.nl> Sender: news@cs.few.eur.nl Reply-To: pk@cs.few.eur.nl Organization: Erasmus University Rotterdam References: <1993Apr8.025858.22137@uvm.edu> <1993Apr11.035322.19610@fcom.cc.utah.edu> <C5FJx6.o5w@ns1.nodak.edu> <1993Apr13.203234.16408@fcom.cc.utah.edu> Date: Wed, 14 Apr 1993 08:58:00 GMT Lines: 58 In <1993Apr13.203234.16408@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: >EBUSY *is* in Posix ..it's ETXTBSY that's missing; but the return value of >EBUSY would be incorrectly overloaded (as if it were a lock) on return from >open(). There is also the issue of an EBUSY resulting from a read/write/ >other operation on a file --this seems (from my reading) to be an illegal >return. Definitely not acceptable. >I think I (and others) need to hit the 1003.1 book and see what can be >slipped in through the cracks in the standard to arrive at the best >approach... this assumes Posix compliance is a goal: it's one of mine, >but potentially not one of Bill and Lynne's... any comments? Ok, I'll bite. The question is whether Posix compliance should be promoted as a primary goal or that it can just be an interesting side-effect of the process of ironing out remaining wrinkles in several interfaces. Posix is incomplete at best, but it can serve as a guideline in the latter case. In my opinion, putting Posix compliance in front of anything else would impair one of the goals put forward by Bill and Lynne which is [quote from the release notes] "to foster new research and development in operating systems and networking technology" . I wouldn't reject beforehand a proposed change to some part the system solely on the ground that it does not adhere to some standards committees document. Given the laudable aim in the above mentioned notes and the fact that many discussions and bug reports in these (comp.os.386bsd.all) groups are not at all specific to 386bsd but of potential interest to all BSD users, I am inclined to believe that such generic discussions are best carried in a generic group (say `comp.unix.bsd' or `comp.bugs.4bsd'). Many bug fixes apply equally well to (I guess) BSDI's BSD/386 and the NET/2 reference base. Wouldn't it be a nice to solicit input on these matters from a broader audience? So, what is the NET's opinion on this? For starters, this group (comp.os.386bsd.development, "Working on 386bsd internals") could carry articles pertinent to the i386/486 architecture, say: - how to best use the chips MMU in the VM system (pmap module) - what to do with those co-processors - development of device drivers of all sorts - issues in boot procedures, disk partitioning etc. In this way, we would be able to more cleanly distinguish "machine independent" from "machine dependent" discussions, in much the same way as this distinction is made in system itself. -pk