Return to BSD News archive
Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!eff!news.byu.edu!cwis.isu.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: File Truncation Philosophy
Message-ID: <1993Apr28.031049.27996@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <C5t8Ft.EE8@sugar.neosoft.com> <1993Apr22.013557.12767@fcom.cc.utah.edu> <C5yn3L.1qA@sugar.neosoft.com>
Date: Wed, 28 Apr 93 03:10:49 GMT
Lines: 191
In article <C5yn3L.1qA@sugar.neosoft.com> peter@NeoSoft.com (Peter da Silva) writes:
>In article <1993Apr22.013557.12767@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>> >> Seriously, the return codes from "system" and "exec" need to be meaningful
>> >> in all cases; that means documented, so that failures can be trapped.
>
>> >Again, you need to trap failures you can handle, and abend or failsoft on
>> >failures you can't.
>
>> Exactly my point -- limit the types of failures that can occur so that they
>> can be trapped.
>
>That means if a new failure mode shows up, that requires a different correction
>mechanism, you can never check for it so you're forever trying to figure out
>a way to kludge things so it doesn't show through to the application.
No, this is a point at which we may make one of two choices, each with
unequal trade-offs in the kernel and in user space. One thing that the
Macintosh has made painfully clear is that if the trade off is between
the user and the programmer (in our case: the application and the kernel),
the decision should be made in favor of the user. Period. You are acting
as if the choice has already be made, when in fact this is not the case;
the 386BSD 0.1 kernel will not return ETXTBSY, it will crash the program
running from the image instead.
Looking to the past, the old memory management system did *not* return
ETXTBSY; this was a "Xenix'ism".
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.
The only potential future standard with the ETXTBSY failure mode is Mach;
I question it's viability in light of newer research systems, such as
"Choices" from the University of Illinois at Urbana-Champaign (a totally
derived-object-class OS written in 100% C++, supporting DOS, UFS, and
VMS file systems).
>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.
>This is one of the main things I see wrong with NFS, for example. If a server
>goes away for a significant amount of time, you should get an ENETCLOSE (NFS
>connection closed) so you can continue (say, give control back to the user)
>instead of hanging forever (or until the user gives up and reboots).
NFS has support for the idea of "stale handles". This seems to handle what
you suggest; it seems the problem would be with your NFS implementation.
But I agree that NFS is antiquated and needs to be replaced -- yet I'm not
personally going to do it tomorrow.
>A programmer should expect that errno will occasionally return values that
>didn't exist when he wrote the program.
Agreed; but the handling of the error is a graceful failure, which may be
a total failure if the program has a lot of state set up that's dependant on
the request not failing or failing in an expected way. Anything above and
beyond that is an expectation of the interfaces changing -- something that
should not be allowed in most cases. Change for changes sake is stupid.
>> It shouldn't assume that the error set will not increase;
>
>But that's just what you said above... that a program should never have
>to deal with new errors.
No, I said that we shouldn't introduce error states which we don't have to
simply to make the code implementing the service easier to write (ie:
because we are to lazy to handle it in the kernel when it's possible to do
so). This is a far cry from saying that programs shouldn't deal with the
future changes that *are* required. The return of ETXTBSY as an error
condition is totally gratuitous.
>> Besides, a program should not have to know the failure recovery procedure
>> for something that can be auto-recovered by the system software.
>
>What's the correct recovery mode?
I've stated it several times; copy the running image to swap before doing
the swap-store damaging operation. If you can't do it, deny the operation
that triggered the necessity of the copy with an insufficient resources
error rather than ETXTBSY.
>> >Broken code is always a problem.
>
>> If you limit the scope of the environment, there will be less broken code
>
>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.
>> (I know; this begs the question regarding portability of code, like you
>> can really be said to have "portable" software if it runs on a Compaq and
>> and IBM machine under DOS).
>
>Try porting a few net programs to Xenix-286. That'll give you some appreciation
>for the amount of junk out there. 386BSD/NetBSD is full of it, by the way.
I would prefer that 386BSD be able to run code from other systems over
other systems being able to run code from 386BSD... it optimizes migration
to 386BSD and pessimizes migration away from it.
>> >What do you mean "it can never happen elsewhere"? It happens on existing
>> >systems right now!
>
>> Only very, very old ones,
>
>System V release 3 isn't that old.
The SVR3 sources I have (don't worry, it's a legal license) are copyright
1984. If 9 years isn't that old, what is?
>> and ones with an "unfixed" MACH VM system.
>
>I've got 200 developers on one of those old systems.
SVR3 or MACH? The MACH problem can be fixed with little work using exactly
the same methods; the SVR3 is old. Face it, in the computer industry,
anything over 2 years old is old, and anything over 4 years is very old;
6 years is very, very old. At 9 years, perhaps I should have said "antique"
instead for SVR3!
>So you copy a new version of Ghostscript in while Ghostscript is running and
>suddenly you're out of VM and the system dies.
>
>Oops.
Fail the copy with an "out of memory". The copy to swap has to occur
*before* the copy can actually keep going. ENOMEM (unlike ETXTBSY) is
something "cp" would expect, and this is correct return for it. A better
way might be to allocate the swap when each process starts, but use it only
on writes of dirty pages rather than copying into it at startup. This
saves us from letting a process start up and then having it fail from
running when it dirties a text page that can't be swapped to the swap
because there isn't any swap left (386BSD currently crashes in it's
entirety, "protecting" the user from an unexpected program crash when
this happens now). I might trash all my text pages, in which case the
only way to guarantee predictable operation is preallocation of swap
area for each program.
>Having a program print "Text File Busy" is a LOT less astonishing.
It's maybe a lot more *meaningful*; it's certainly not intuitive. Say you
are Joe Avereage User, and you get "Text File Busy" doing a make -- what
the hell do you do now? The question is relevant, because good old Joe
doesn't know *why* he got the error. First, he has to find out *why*,
and then he has to know how the *why* applies to the command he was using
(say... time to break out the O'Reilly book on makefiles and learn how
they work so we can tell whqt it's doing), and only *then* will he be able
to take corrective action -- if he can figure out *what* "corrective action"
is.
>> Don't change an existing system so that it generates errors
>> which are not trapped in existing software.
>
>Any existing software that can't deal with ETXTBSY is broken on a lot of
>existing systems. But, while we're playing with rules:
>
> 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!
Terry Lambert
terry@icarus.weber.edu
---
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
-------------------------------------------------------------------------------