tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: GSoC, translators

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,

Attachment: signature.asc
Description: This is a digitally signed message part.

Home | Main Index | Thread Index | Old Index