Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!haven.umd.edu!uunet!mcsun!news.funet.fi!hydra!klaava!lukka From: lukka@klaava.Helsinki.FI (Tuomas J Lukka) Subject: POSIX, compatibility with (was: Re: File Truncation Philosophy Message-ID: <1993Apr28.113238.13749@klaava.Helsinki.FI> Summary: Optional posix? Organization: University of Helsinki References: <1993Apr22.013557.12767@fcom.cc.utah.edu> <C5yn3L.1qA@sugar.neosoft.com> <1993Apr28.031049.27996@fcom.cc.utah.edu> Date: Wed, 28 Apr 1993 11:32:38 GMT Lines: 64 >Looking at the future, Posix compliant systems do *not* return ETXTBSY. I >note Posix as the future only from the point of view that I believe >standards compliance is an important requisite for government contracts >and for use in large business sitautions. I see both of these as being >desirable for 386BSD's viability. Untrue (as far as I know). Posix explicitly states that implementations may return errors not specified in the document or may have extensions or something that prevent an error specified from being returned ... Look at section 2.4 (this just came up in the linux world, also...) NOTE: I do not have the original posix documents to check this reference, I just happened to come across it in the linux-activists mailing list. TJL >>That is, failures occur. Handle them. Chewing up extra swap space (and >>increasing the chance of some unrelated process dying) is less desirable >>than returning a failure condition (ETXTBSY). > >You would fail (with ENOMEM) the operation triggering the copy-to-swap of >the image instead of trashing the already running process which needs to >be copied to swap -- the process triggering the copy, not the process being >copied is the process that gets failed. YUCK! >>No, there will be just as much broken code... it will just hide out until a >>new failure mode you can't sweep under the rug develops. > >Fine; as long as it is hidden, I can't see it. Anything that works is >better than anything that doesn't work. Using the "ETXTBSY" failure mode >I can't install over a running image and reboot to activate the new image. > >If you are absolutely in patulous love with the idea of returning ETXTBSY >to make 386BSD fail Posix validation, return it to the program that would >normally get it immediately only in the case of the copy swap-store to swap >failing so that it *at least* occurs less frequently and we can sneak it >past a badly written validation suite. And also, a suggestion: this kind of things should be an option settable on user- or process basis. Make it possible to for root to create entirely-posix users, processes etc. and the state flags go with the process when forking. Make an interface for a process specific to 386BSD to change itself back to the 'normal' semantics. I think this could be used to make 386BSD compatible with a lot of systems. It's a kludge, however :) >> KISS > >I agree with the KISS principle -- as a matter of fact, let's keep the >"open", "creat", and other tuncating interfaces simple by *not* returning >ETXTBSY! Is it truly simpler to return a specific error for a specific case or, as you suggest, overload stuff? TJL