Return to BSD News archive
Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!decwrl!uunet!mcsun!dxcern!vxcrna.cern.ch!roeber
From: roeber@vxcrna.cern.ch
Subject: Re: A challenge to all true hackers: objects and types
Message-ID: <1993Mar25.184157.1@vxcrna.cern.ch>
Sender: news@dxcern.cern.ch (USENET News System)
Reply-To: roeber@cern.ch
Organization: CERN -- European Organization for Nuclear Research
References: <JKH.93Mar20153113@whisker.lotus.ie> <ARNEJ.93Mar24113744@chanur.imf.unit.no> <C4FEo2.8no@sugar.neosoft.com> <1osl3b$8vl@umd5.umd.edu>
Date: Thu, 25 Mar 1993 17:41:57 GMT
Lines: 69
In article <1osl3b$8vl@umd5.umd.edu>, mark@roissy.umd.edu (Mark Sienkiewicz) writes:
> In article <C4FEo2.8no@sugar.neosoft.com> peter@NeoSoft.com (Peter da Silva) writes:
>>In article <ARNEJ.93Mar24113744@chanur.imf.unit.no> arnej@imf.unit.no (Arne Henrik Juul) writes:
>>> I also think that variant links using environment variables is a BAD
>>> idea.
>>
>>I think that's a reasonable conclusion. How about variant links using
>>some other set of per-process/per-uid symbolic name space?
>
> Using environment variables is a BAD idea for this reason:
>
> Environment variables do not exist.
>
> They are a fiction that is maintained by the user level programs. The
> kernel does not maintain them. They are an array of strings that are
> stored _somewhere_ in the user process, but they are entirely under the
> control of the user process. The kernel can't even be sure it can find
> them.
Who said the kernel would need them? In the Apollo system, and in my
suggestion, the type managers are user-space shared libraries. The process
opens a variant link, the type manager converts the name, and the kernel
sees the process opening the actual, real name.
This is how I was able to create a "search list" type for the Apollos.
I didn't touch the kernel.
> Hewlett Packard has an interesting feature that was mentioned at the
> beginning of this discussion. It is "Context Dependent Files". A CDF is
> essentially invisible. When you access the directory, you don't get the
> directory, but you get a file _within_ the directory. Which file is based
> on your "context".
Interesting, yes, but hardly to be duplicated. This is just another case
of where HP has had its hands on an elegant solution (since they took over
Apollo), threw it out the window, tried to re-invent a limited subset of the
functionality, and ended up with a horrible bletcherosity of a hack.
(Apollos solve the same problem with a "cmpexe" compound executable type.)
If people want CDFs, I say the best solution is to come up with a general
trait/type/object system, and allow these things (CDFs, variant links,
"links using some other name space", search lists) to be specific types.
I do agree that using environment variables in a variant link increases
greatly the number of ways one can shoot oneself in the foot. One of the
problems with Apollos is that people use features like variant links without
using the Apollos' security model -- they use just the unix security.
Since I suspect nobody's going to beef up unix security any time soon, I
suggest we don't use exactly Apollo-style variant links of the type
/bin -> /$(CPU)/bin
in important areas, but perhaps one with a more limited syntax, e.g.
/bin -> /$(CPU:{m68k,pa,386})/bin
But this is all beside the point: the big question is, "Do we change the
'file' system to be a more flexible object-store and allow people to
easily write new types, or do we keep the present model and introduce
things one by one in incremental ad-hoc kernel hacks?"
--
Frederick G. M. Roeber | CERN -- European Center for Nuclear Research
e-mail: roeber@cern.ch or roeber@caltech.edu | work: +41 22 767 31 80
r-mail: CERN/PPE, 1211 Geneva 23, Switzerland | home: +33 50 20 82 99
--
"Sorry, baby, I can't take you to the pizza joint tonight, I've got to go
back to the lab and split the atom." -- Ayn Rand, "What is Romanticism?"