From owner-freebsd-hackers Fri Jan 27 12:56:22 1995 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id MAA27286 for hackers-outgoing; Fri, 27 Jan 1995 12:56:22 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.223.46]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id MAA27280 for ; Fri, 27 Jan 1995 12:56:21 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.9/8.6.9) with SMTP id MAA03197; Fri, 27 Jan 1995 12:56:07 -0800 To: Garrett Wollman cc: hackers@freefall.cdrom.com Subject: Re: Am I dreaming? In-reply-to: Your message of "Fri, 27 Jan 95 15:28:01 EST." <9501272028.AA12182@halloran-eldar.lcs.mit.edu> Date: Fri, 27 Jan 1995 12:56:06 -0800 Message-ID: <3196.791240166@time.cdrom.com> From: "Jordan K. Hubbard" Sender: hackers-owner@FreeBSD.org Precedence: bulk >> I guess this all gets back to the whole `user mode translation of file names' >> thing we were talking about awhile back. It's not the same as portals, >> which require a given mount point to be traversed, but rather affects all >> files who's names match some sort of selection criteria. The feature above >> would be one very nice application for this. > > Gross! That's even more evil than variant symbolic links! Heh, you bet! :-) Actually, the more I think about it the more I realize that it probably can't be made to work. Sure, you could put in a hook so that a process could register itself with namei() [if the hook was NULL, namei() would simply always skip over it] and get called via some mechanism that would allow it to pre-massage the name and pass it back (perhaps totally transformed) to namei() for further processing. For most names, the process would simply pass it back unchanged, but for the hairy ftp://.. stuff it would fetch the file and pass namei() back the name of something in /tmp. The problem is, what does namei() do while the process is talking to some server halfway around the world? We certainly can't block in the kernel waiting or all the other users on the system would vomit up their entrails, and a `wake me up when you're done, please' mechanism would be a lot more work to implement. Perhaps we should forget that I even suggested it.. :-) However, I do feel compelled to note that the inability to do this kind of thing easily only underscores the abominable evil that is the whole UNIX filesystem paradigm (as if ioctl() wasn't enough to already convince us of this! :-). Jordan