Date: Sat, 28 Jan 1995 02:29:29 +0000 (MST) From: Jeremy Chatfield <jdc@crab.xinside.com> To: jkh@FreeBSD.org (Jordan K. Hubbard) Cc: wollman@halloran-eldar.lcs.mit.edu, hackers@freefall.cdrom.com Subject: Re: Am I dreaming? Message-ID: <199501280929.CAA16417@crab.xinside.com> In-Reply-To: <3196.791240166@time.cdrom.com> from "Jordan K. Hubbard" at Jan 27, 95 12:56:06 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Jordan K. Hubbard writes: > >> 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. > > 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. The automount daemon circumvents the same problem appearing for NFS. Life goes on while the automounter tracks down and mounts the required resource... It's been a while since I ran a network large enough to justify automounting, but I don't remember any system delays while the node was found and mounted. Would it be useful to consider what & how the automounter achieves its' effects? Note that I'm not advocating copying the automount daemon behavior directly; my previous experience was with a well known SVR4.2 implementation and I had to rescue many users from strange system behaviours when the daemon died, or when the user managed to delete the directory structure that propped up the daemon :-) Another way to tackle the problem would be to have another file system type, mounted on /ftp by convention, with the FQDN used as the next component. By making this as a file system in its' own right, you should be able to sidestep some of the nasty issues involved in handling the special file within existing file systems. The symlink in the original example would simply point to /ftp/freefall.cdrom.com/... rather than using the URL semantic. By pushing this handling towards user space, you can also allow the per-user .netrc govern the behaviour, make a move to a more network security oriented approach (.profile --> ftp://....? I think not!) and make centralised administration easier. Some consideration would have to be given to how to handle FTP login and init macros for daemons rather than real users, which would probably revolve around identifying the correct home directory for each system id, rather than having half share /root and others in places like /tmp. This mechanism would let you skip a namei(), unless an FQPN (Fully Qualified Path Name) is given. For example, 'ls /ftp' yields nothing (unless there is a current open connection?), but 'ls /ftp/wuarchive.wustl.edu/pub' results in a listing. The effect that you are trying to achieve is approximately the same as AFS, isn't it? Rather than define a whole new semantic, why not port AFS (he said, confident that *he*, at least, would not have time to contribute effort). Cheers, JeremyC. -- Jeremy Chatfield, +1(303)470-5302, FAX:+1(303)470-5513, email:jdc@xinside.com X Inside Inc, P O Box 10774, Golden, CO 80401-0610, USA. Commercial X Server - for more information please try these services http://www.xinside.com info@xinside.com ftp.xinside.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199501280929.CAA16417>