Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!swrinde!sdd.hp.com!zaphod.mps.ohio-state.edu!menudo.uh.edu!uuneo!sugar!peter From: peter@NeoSoft.com (Peter da Silva) Subject: Re: A challenge to all true hackers: objects and types Organization: NeoSoft Communications Services -- (713) 684-5900 Date: Wed, 31 Mar 1993 18:27:33 GMT Message-ID: <C4rn9y.FMy@sugar.neosoft.com> References: <1993Mar27.081223.2547@fcom.cc.utah.edu> <C4M2CH.1Cp@sugar.neosoft.com> <1993Mar30.234859.23609@fcom.cc.utah.edu> Lines: 59 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. > 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. > 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. > 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. > 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. 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. > 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? -- Peter da Silva. <peter@sugar.neosoft.com>. `-_-' Oletko halannut suttasi tänään? 'U` Tarjoilija, tämä ateria elää vielä.