Return to BSD News archive
Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!spool.mu.edu!howland.reston.ans.net!agate!dog.ee.lbl.gov!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: <1993Apr7.224553.333@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <C4M2CH.1Cp@sugar.neosoft.com> <1993Mar30.234859.23609@fcom.cc.utah.edu> <C4rn9y.FMy@sugar.neosoft.com>
Date: Wed, 7 Apr 93 22:45:53 GMT
Lines: 136
In article <C4rn9y.FMy@sugar.neosoft.com> peter@NeoSoft.com (Peter da Silva) writes:
>In article <1993Mar30.234859.23609@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>> 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.
>
>Yeh, but you can't have file system semantics depending on a process being
>not only well behaved but refraining from use of a documented interface.
From the "putenv" man page, wherewith it is "well documented":
] WARNINGS
] putenv() manipulates the environment pointed to by environ,
] and can be used in conjunction with getenv(). However, envp
] (the third argument to main) is not changed.
]
] This routine uses malloc(3V) to enlarge the environment.
]
] After putenv() is called, environmental variables are not in
] alphabetical order.
]
] A potential error is to call putenv() with an automatic
] variable as the argument, then exit the calling function
] while string is still part of the environment.
Basically, kernel-based lookups into a processes environment (given the
current storage mechanism for the environment) involve the kernel knowing
where "envp" lives, *not* "environ". Lookup is off of "envp".
>> 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.
>
>Could you translate that? Does this mean:
>
> it's OK if they're files, not directories.
> it's OK if they're compilete file names, not parts of one.
Neither. A "terminal file system name space object" is a path component; the
correct synopsis would be:
it's OK if they're compilete path component names, not parts of
path component names.
This is pretty much the only way to remain POSIX compliant and have them,
and even then it takes a pretty lenient reading to let it get by.
>> 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.
>
>I don't believe I was advocating putting them anywhere *other than* outside
>the address space of a user process.
Nope; this was to answer the "make it part of the 'open' library call" crowd
and their friends, the "make it part of the per FS VOP_OPEN" crowd.
>> 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.
>
>That's an implementation detail that I don't want to get into at this point.
>I'm more interested in dealing with the semantics.
Just an example to show that a working/conforming implementation is possible.
>> Of
>> course, one could implement the user environment in approximately the same
>> way, providing a system call interface for getenv/putenv.
>
>That would be reasonably cool. The Amiga does this, and I haven't found
>many problems porting stuff to it. At least not because of this. You could
>always have a copy in the user's namespace for older programs to read.
And if you dealt with inheritance issues by including an additional pointer
and flag, you get group logical name tables at nearly no cost in their
implementation. A system logical name table could be global in kernel memory.
>I'd suggest that getenv/putenv be a special case of a general logical
>symbol name space, *AND* that that namespace be exposed to the file system
>via (say) /env/pid/sym...
>
>In fact, getenv/putenv could sumply do open-read/write-close on your own
>process ID's files.
The suggestion that the "environment" be a special case is the same as making
it the process local logical name table; I agree with this in principle if
we have to be able to modify the environment to buy variant links; once
this is in place, then it boils down to usage semantics and little else,
although it does make older binaries unloadable unless we support a different
magic number for newer code and keep the old loader/crt0. I kind of wanted
to avoid grandfathering.
I think the file system exposure is a bit expensive in terms of your
average environment variable/logical name requiring much less than a VM
buffer to hold, and per-entry name exposure would require a gret deal of
expensive operations during the manipulations, since the idea of putting
in the kernel rather than user address space implies that without a unified
cache, we'd have to do a great deal of faking to get it to work. I'd hold
off on this for better external access to the scheduler to let us put it
as part of a /proc file system if we are to provide FS exposure to it at
all (after all, the system call for get/put could easily take a PID to
allow inter-process modification of tables, assuming appropriate credentials
were enforced).
>> 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...
>
>How, then?
Simply use the existing environment at the time the process is created; other
than shell redirection, this should have nearly no impact; it's simply a
limitation on allowable usage... not a bad restriction. The shell redirection
problem only surfaces with link creation and use occuring in the same process
that defined the link; all of the usages discussed so far have not created a
situation where this would be hit (mostly it's been discussed for use in
remote boot disks and unified /etc and /bin servers for multiple processor
architectures).
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
-------------------------------------------------------------------------------