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!cs.utexas.edu!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: A challenge to all true hackers: objects and types
Message-ID: <1993Mar30.234859.23609@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <C4FEo2.8no@sugar.neosoft.com> <1993Mar27.081223.2547@fcom.cc.utah.edu> <C4M2CH.1Cp@sugar.neosoft.com>
Date: Tue, 30 Mar 93 23:48:59 GMT
Lines: 80
In article <C4M2CH.1Cp@sugar.neosoft.com> peter@NeoSoft.com (Peter da Silva) writes:
>In article <1993Mar27.081223.2547@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>> As I pointed out in the previous post, this is based on the bad assumption
>> that a process may modify it's own environment or that of it's parent, both
>> of which are not allowed.
>
>A process may well modify its own environment. Whether that's "allowed" or not,
>it's possible. I've done it (mostly to reclaim space on PDP-11 versions of
>software, where the K or so in the environment was a significant amount of
>the available BSS), and I'm sure other people have too.
This is an exception, I believe. The point is that modification bu "putenv"
type calls generally does not affect the information in the copy from the
parent; you'd have to go looking elsewhere.
>> An "environmnet that isn't" is functionally equivalent to process or system
>> logical names (ala VMS), depending on implementation.
>
>And just because VMS does it you reject it? It's VERY useful under OpenNET.
No, I don't reject it. I have a long history with VMS (11 years at least),
and agree that logical name tables, especially in a functional heirarchy,
are useful things. They do, however, change semantics to the point of
POSIX incompatability unless they are *not* used as a *part* of a terminal
file system name space object instead of *as* a terminal file system
name space object.
UNIX logical naming was not the problem under discussion; the soloution
proposed solves the logical name problem, not the variant link problem;
also note that it's possible to resolve the issue of variable length
file objects using the FS as an object store; this does however require
changes to the lookup and inode store mechanisms... not a minor undertaking.
Without extensive modification, the idea of embedding the equivalent of
logical names within the file system rather than at the VFS layer itself
(to allow their use in links) simply does not pay off.
On a different subject, implementing system, group, and user logical name
tables within the VFS layer itself isn't a bad idea; I would, however,
refrain from allowing logical name translation of symbolic link contents,
since the translation must be assumed to have occurred prior to entry of
the lookup() or namei() routines to avoid two stage alias looping requiring
some means of examining stack variables to determine transitive closure
and bail out.
The issue with logical names is that they be stored in an allocated block
of kernel memory hung off of the proc struct, probably link-listed with
extension blocks to allow growth of the table within the process. Of
course, one could implement the user environment in approximately the same
way, providing a system call interface for getenv/putenv. At that point,
the difference between a proceess logical name table and an environment
would be very small.
Logical names are useful, and should probably be implemented, if for no
other reason, to support 386BSD as a file server platform. I think that
your "reclamation" scenerio is a good argument that we should not (and
indeed can not!) change the way the environment is stored without a *lot*
of thought.
In the mean time, we don't need to go to the level of providing a logical
naming interface with it's concommitant changes to the proc struct to
get the functionality provided by variant links... namely, vastly
simplified remote booting and unified directory views supporting binaries
for multiple platforms running 386BSD.
PS 386BSD will probably be running on many platforms besides just the
386; what should we call it then?
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
-------------------------------------------------------------------------------