*BSD News Article 15291


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