Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!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 kernel hackers - conditional symlinks. Organization: NeoSoft Communications Services -- (713) 684-5900 Date: Thu, 11 Mar 1993 01:14:58 GMT Message-ID: <C3pA4z.7CG@sugar.neosoft.com> References: <JKH.93Mar9214944@whisker.lotus.ie> Lines: 43 In article <JKH.93Mar9214944@whisker.lotus.ie> jkh@whisker.lotus.ie (Jordan K. Hubbard) writes: > Finally (this is leading somewhere, honest) you had Apollo's > beautifully simple, yet very powerful, mechanism for doing symlinks, > which was to allow environment variables to be imbeded anywhere within > a link name. As you mention, it'd be hard to get at the real environment. What would be nice would be to have some way of exporting this stuff into the kernel. On intel's OpenNET system, namei does a preparatory lookup on the file name in a couple of tables, one per UID and one global (only root can diddle with the global one). So you can do: rdr @tmp /usr1/tmp Then when any process owned by you accessed "@tmp" it got "/usr/tmp". This is how the network supports the "supperroot". "//xds13" gets handled by this mechanism and the rest of the filename is passed to the remote system intact. In a symbolic link world this is less useful, and the latest OpenNET doesn't have it. But you can see how part of the idea would be useful: the per-uid and (new) a per-pid namespace that namei can look at. It'd be *this* name space that symlinks would expand: assign LANG english ln -s /usr/i18n/$(LANG)/docs /usr/docs Or: assign -uid LANG english Or: assign -world LANG english This gives you a default mechanism to handle the case where LANG isn't set. -- Peter da Silva. <peter@sugar.neosoft.com>. `-_-' Oletko halannut suttasi tänään? 'U` Tarjoilija, tämä ateria elää vielä.