Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!usc!cs.utexas.edu!uunet!pipex!uknet!mcsun!news.funet.fi!hydra!klaava!lukka From: lukka@klaava.Helsinki.FI (Tuomas J Lukka) Subject: Re: POSIX, compatibility with (was: Re: File Truncation Philosophy Message-ID: <1993Apr30.144806.11417@klaava.Helsinki.FI> Organization: University of Helsinki References: <1993Apr28.031049.27996@fcom.cc.utah.edu> <1993Apr28.113238.13749@klaava.Helsinki.FI> <1993Apr29.210327.27310@fcom.cc.utah.edu> Date: Fri, 30 Apr 1993 14:48:06 GMT Lines: 167 In article <1993Apr29.210327.27310@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: >In article <1993Apr28.113238.13749@klaava.Helsinki.FI> lukka@klaava.Helsinki.FI (Tuomas J Lukka) writes: >>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. > >I have the 1003.2-1988 and other related Posix documents as well; the issue >is not one of OS Posix compliance, and perhaps I haven't made that clear. >The issue is being able to run programs written for the documented interface >in the standard *without extensions*. As already stated by mr. Urlichs, since the Posix document _itself_ standardizes the fact that implementations *may extend it* and *still* be Posix-compliant, this is theoretically not true. However, I do see your point more clearly now, thank you for clarifying the point. >Any extension we make, whether or not allowed, and expecially to fundamental >services like process creation, risks our ability to run strictly compliant >programs. I object to making extensions to what may be returned by exec(); >obviously, we will have to live with some changes -- ESTALE for a stale >NFS file handle is a good example. If possible, we should limit the scope >of these changes. Returning ETXTBSY because we have changed the VM system >and basically broken it for certain normal operations (like writing system >dump images to swap and installing updated software) is gratuitous, not >necessary, and generally a bad idea in any case. As said, a strictly compliant program should be prepared to receive EBUSY from fork()... The way I see it, the posix defined error codes are a MINIMAL set and represent the most common cases of errors, which the application should be able to handle. Someone could make a strictly posix-compliant operating system on a *sci-fi toaster* and return EOUTOFBUTTER on a write. The application, if strictly posix-compliant, would probably just log this somewhere or complain to the user etc. >Posix compliance, taken in the broader sense, should mean that 386BSD will >be capable of running programs from other Posix compliant systems with >no changes to the sources (source code compatability) and even binaries >from other Posix compliant systems with the same processor architecture >(binary compatability with Linux, MACH, and SVR4). Extending the interface >for no good reason, while allowed, should be discouraged. I am discouraging >it. Right now you are defining posix compliance in a sense that posix probably never was intended to be. The toaster is posix compliant, BUT 386BSD would not be able to run a program from it if the program used its special features (a library function toast();). There is *no* system in existance which is STRICTLY posix, each and every one of them have extensions. The program has to be written to be posix-compliant and tobe prepared for every contingency. >>>>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! > >This "YUCK" is the result of a VM system that does not require sufficient >swap to store the entirety of all process images running on the system, >does not provide a backing store for main memory to permit a full system >dump, and allows swapping read-only text pages in from the executable image, >providing a drastically reduced image load time (with the expense of going >through a two stage swap for additional pages later due to a non-unified >VM and FS buffer cache). Clearly, this is a trade off for running small >programs *fast* on the assumption that interactive programs are likely to >be small -- this bolsters the appearance of speed for interactive users >of the system. Actually, that YUCK is the result of the ORIGINAL unix swapping with no virtual memory. Look, that was then. In the past. You just can't make up a paradigm and expect every aspect of it to be perfect and last forever. >If you can suggest an alternative that does not disallow the fast startup >(a unified VM/buffer cache is not a valid suggestion; it's already in 0.2) >then I will be happy to try to implement it. Yes, 0.2: the new version, created in a vacuum... This is exactly the reason I prefer linux, since there is interaction with the developer and the users... But back to the point: I really think that the swapping paradigm of unix has lasted long enough and is not usable any longer. The solution I suggest still is ETXTBUSY >>>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. BTW: in the beginning you contradicted this: you said it was not about posix compliance/validation but a 'broader sense' as you call it... Should we strip the symbolic links off now? :) >>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 :) > >This is similar to the derived process class concepts in the "Choices" >operating system. If you are truly interested in this kind of approach, >check out the technical paper and simulator on cs.uiuc.edu:/pub/Choices. I will, definitely! Thank you for the reference! >Since we aren't running processes as objects, and we don't yet support >kernel light weight processes or tasks, this isn't really an option for >us (yet). Why? Just a table of flags in the process descriptor structure... That's why I said it was a kludge! (As a matter of fact, I suspect that WFJ will be trying something like this with the new C++ kernel and all...) >>>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? > >The error return is the correct one for the circumstance; even in a swap >stored VM system, if a user has a 4M partition with a 3M file open on it, >and someone wants to overwrite it, there must be 6M free on the partition. True.... >Alternately, "SIGLOST" could be returned to the process that caused the >copy-to-swap to be required, or the process causing the copy could be >blocked until such time as sufficient swap was available (meaning there >is *no* failure condition, and therefore *no* overloaded or additional >error return); after all, there is no reason why we must only consider >the recovery as a non-blocking operation. Yes there is... writes to a normal file are 'fast' operation in the sense of signals, and unless you want to make another kludge in the kernel for making it behave like this, ... oh well. >In any case, ETXTBSY is antiquated and should not be reintroduced to cover >up a problem that can be resolved using other approaches. Reintroduction >is simply an admision of failure on our part to adequately deal with the >problems in the VM system. An admission of failure on the part of posix to emphasize the expandability and different error returns, I think... TJL