Return to BSD News archive
Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!foxhound.dsto.gov.au!fang.dsto.gov.au!yoyo.aarnet.edu.au!news.adelaide.edu.au!news.cs.su.oz.au!harbinger.cc.monash.edu.au!yeshua.marcam.com!MathWorks.Com!europa.eng.gtefsd.com!gatech!newsxfer.itd.umich.edu!nntp.cs.ubc.ca!news.UVic.CA!softwords!cue.bc.ca!jnemeth
From: jnemeth@cue.bc.ca (John Nemeth)
Subject: Re: Notes on the *new* FreeBSD V1.1 VM system
Message-ID: <1994Mar10.081308.101@softwords.bc.ca>
Sender: news@softwords.bc.ca (CNews)
Nntp-Posting-Host: cue.bc.ca
Organization: Computer Using Educators of B.C., Canada
References: <1994Mar1.132637.58107@ans.net> <a09878.762550221@giant> <2l0b06$2qi@GRAPEVINE.LCS.MIT.EDU>
Date: Thu, 10 Mar 94 08:13:08 GMT
Lines: 63
*FLAME ON*
This flame isn't directed at Garrett or anybody else in particular.
In article <2l0b06$2qi@GRAPEVINE.LCS.MIT.EDU> wollman@ginger.lcs.mit.edu (Garrett Wollman) writes:
>In article <a09878.762550221@giant>,
>Curt Sampson <a09878@giant.rsoft.bc.ca> wrote:
>
>>But isn't this what the vfork() system call is for?
>
>vfork() isn't POSIX. But then, neither is memory overcommit.
Who gives a d*mn about POSIX. POSIX has broken setuid(),
signal(), job control, and most likely a lot of other stuff. Its
about time that we in the grassroots community gave some intelligent
thought to what standards we adopt, how much we adopt, and how we
implement them instead of acting like lemmings and blindly adopt every
standard that comes down the turnpike (i.e. POSIX, XPG3, SVID,
X.<whatever>, etc., etc.). There are many good standards out there,
but there are also many problematic ones.
Somebody over in the security groups was talking about how the
POSIX setuid() call affects programs like xterm that need to run as
root at various times, but not all the time. He suggested that xterm
should fork() a child to perform root tasks and the parent should
relinguish root privs. My answer is if setuid() is broken then fix
it. If adopting POSIX will break setuid(), then don't adopt it, at
least not in its entirety. BSD has been around long enough and has a
wide enough installed base that it is a standard unto itself. We
don't have to adopt every part of every standard that comes down the
turnpike.
Since I'm flame mode, I might as well hit memory overcommit too.
I'm another one like Terry Lambert that gets religious about things
like that. The idea of overcommitting memory and then killing random
processes is absolutely unacceptable. Let's try not to pick up System
V's bad behaviour. If I wanted System V, I would go to Linux.
>But you then get into interesting questions like:
>
>Say my default stack limit is 256MB. Does that mean that I have to
>have 256MB of backing store available to start any new process? If
>so, will you pay for all my disks from now on? If not, why not, and
>what happens when a stack grow causes you to run out of memory?
Yes, this is an interesting question and one which I will have to
think about. Obviously, given today's technology, having to have
256+MB of backing store available for every fork() or exec() is not
feasible. The good thing is that the process growing without bounds
is the one that is most likely to get killed, as opposed to some
random process. One possibility would be to block the process until
memory is available, but this invites deadlock, so we would have to be
extremely careful in implementing it.
*FLAME OFF*
Well, time to go get a new pair of asbestos underwear. The last
time I got flamed was the last time I bashed POSIX, but I felt this
needed to be said.
--
John Nemeth jnemeth@cue.bc.ca
System Administrator
Computer Using Educators of B.C. Opinions are my own.