Sunday 27 of April 2008 03:55:25 napisałeś(-łaś): > I'm not sure that's quite the same thing as a mount point. If I > understand what you're saying correctly (not guaranteed), a translator > is a new fs-level inode type as stored on disk. Touching this inode > fires up some mechanism (based I assume on the inode contents) that > then handles all vnode operations and can thereby appear as any > arbitrary kind of vnode/inode. Both yes and no. Inode of any type can have a translator set. In Hurd in both ffs and ext2 it is implemented in a very simple way: one of the reserved fields in dinode points to a block in which the path and arguments of the translator are stored. Translator unaware systems may mount a filesystem with translators usually and will see the regular contents of the file (not translated). The only pain is that fsck may want to correct the free blocks count etc, because it doesn't know about translators. But indeed it is true that a translator set on a regular file may tell the VFS that it is a directory. For example the hypothetical translator which would allow you to chdir to a tar.gz. > > It is thus more or less a generalization of named pipes or device > special files, in the sense that these things are a magic fs-level > objects such that touching them fires up a non-fs kernel mechanism > that handles all subsequent vnode operations. I agree, but it is a different way of handling VFS operations on the existing types of objects. > > While this facility can be used as an automounter, in the case where > what the translator does is masquerade as a directory and mount a fs > on that directory, it's not really quite the same as a mount point. I agree that this is something more, but the only thing I wanted to say in that point is that when lookup function is run, it checks if a directory isn't a mount point and if it is, instead of doing the lookup on the original tree it continues on the fs tree associated with the mount point. I think that hooks for searching for the appropriate inode in the translator instead of the orignial tree should be done the same way, however it would require a modification that would check if the translator was set not only on directories but also on other objects. > > Naive question (since I haven't read any more than this thread yet): > does the implementation you're intending allow a translator to give > the appearance of itself being a (different) translator? I don't quite understand the question. Could you please explain what do you mean by "giving the appearance of being a translator"? I am not sure if I was clear enoguh so I please tell me if I wasn't. -- Marek Dopiera marek%dopiera.pl@localhost, http://dopiera.pl JID: siersciu%jabberpl.org@localhost
Attachment:
signature.asc
Description: This is a digitally signed message part.