Return to BSD News archive
Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!convex!convex!cs.utexas.edu!swrinde!gatech!news.byu.edu!ns.novell.com!gateway.univel.com!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: POSIX, compatibility with (was: Re: File Truncation Philosophy
Message-ID: <1993Apr29.210327.27310@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <C5yn3L.1qA@sugar.neosoft.com> <1993Apr28.031049.27996@fcom.cc.utah.edu> <1993Apr28.113238.13749@klaava.Helsinki.FI>
Date: Thu, 29 Apr 93 21:03:27 GMT
Lines: 131
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*.
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.
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.
>>>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.
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.
>>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 :)
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.
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).
>>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.
In the case of "open(2)", this should probably be "ENOSPC" rather than
"ENOMEM". My suggestion of "ENOMEM" was predicated on it returning some
type of resource restriction error. If this ends up being "ETXTBSY", it's
better that an attempt at error avoidance was made before the error is
returned and the operation is failed. My thinking on this is that the
"new" error will only occur in the case of running out of swap space, and
a lack of proper swap allocation is likely to show up elsewhere first. A
strictly complying Posix interfaced application would still have the
possibility of failure; however, the probability will have been greatly
reduced.
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.
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.
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------