Date: Sat, 25 Mar 1995 08:23:43 -0800 From: "Jordan K. Hubbard" <jkh@freefall.cdrom.com> To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Cc: freebsd-hackers@FreeBSD.org (FreeBSD hackers) Subject: Re: env-dependant symlinks [Was: DEC Alpha Multia (fwd)] Message-ID: <25510.796148623@freefall.cdrom.com> In-Reply-To: Your message of "Sat, 25 Mar 95 11:32:27 %2B0100." <199503251032.LAA12525@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> I've seen this on Data General's DG/UX. They do have so-called > ``elinks'', i.e. symlinks starting with the string "elink:". They are > used to switch between different software development environments, > and they made their development tools (cc, as, ld, nm, ar) aware of > them, and resolve the paths there. Other tools can easily made aware > of them, too (including scripts), by simply looking what the links > points to, and resolving it in their own context. Hmmmm. Ack! I really don't like the idea of having to make all the tools aware of it - it just... rubs me the wrong way! What we REALLY need, I suppose, is a way for another daemon process to attach itself (well, maybe one or more daemons) and register itself as a "translator" somehow. It would also have to have a method for slurping context out of other processes if the environment expansion were to work, but I imagine that this isn't totally impossible.. What I'm sort of really driving at is QNX's approach (which Gary will remember a long conversation with them at CeBIT about :-). They have a mechanism whereby a daemon can connect and say to the system: "I own this part of the filename space" and the system will pass all such requests to it. The "longest match" wins in the matching algorithm, so if you have these two daemons: dev_fs (owning) /dev fd_fs (owning) /dev/fd Then an open of /dev/foo will get passed to the dev_fs daemon. If you open /dev/fd/1 then it will be passed to the fd_fs daemon. The fd_fs daemon gets precedence over /dev since it owns the longest match. My long conversation with them centered around whether or not it would be possible to own "non-UNIX parts of the filename space", e.g. register yourself as owning "^(.*)::(.*)$" (though perhaps not with that expensive a syntax, of course :-) and then get all DECNET file specifications. My favorite "URL filespec" would also be handled by registering yourself for "ftp://(.*)". They thought about this for a good long while and concluded that it would be cool and that they'd get back to me.. :-) There are serious reasons for wanting this, of course. The URL filespec would enable you to create meta-ftp servers which just contained many thousands of links to other places transparently. The DECNET filespec stuff would be VERY VERY useful for poor fools like myself who've been tasked with porting VMS legacy code onto UNIX. Hackers often like to hard-code stuff like this, and you could either pour through megabytes of spaghettic code looking for all such things (traditional method) or you could simply trap the filename lookups and do something sensible with them outside the program entirely. Assuming that a process's environment got more accessible to the system, you could even do the ${...} translation (register for ^(.*)\${(.*)}(.*)$). It would all be very very powerful and also very very expensive if you couldn't come up with a really nice and fast pattern matching algorithm for matching up an arbitrary name to any services that had registered for it. It wouldn't be THAT hard, of course. You do have the liberty of being able to precompile the patterns to an optimal form when the service daemon connects and registers its pattern, and the namei cache could probably be pressed creatively into service somehow. Oh well, I can dream, can't I? :-) Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25510.796148623>