Re: Symlink, chrdev, blkdev translators

[Marcus Brinkmann]

On Mon, Aug 19, 2002 at 02:23:47PM +0200, Ludovic Courtès wrote:
> It seems to me that there exist some kind of "fake" or "magic" translators
> which show up "automatically".

Oh yes, there are!  You found another underdocumented exciting Hurd feature ;)

> ludo@hurd:~/trans/tarfs/t$ showtrans *
> 2-type-symlink: /hurd/symlink file
> 3-type-cdev: /hurd/chrdev 0 0
> 4-type-bdev: /hurd/blkdev 0 0
> 6-type-fifo: /hurd/fifo
> 
> /hurd/???dev do not exist, and /hurd/symlink is not running (not that
> the netfs_set_translator() callback of this filesystem *always* returns EROFS
> without doing anything). So where do they come from?

Let me counter with a question:  Where do you expect device nodes, fifos and
symlinks to come from if not from translator settings?  There is no function
in the Hurd server interfaces (like fs.defs) to "set a symlink", "create a
device node" or "make a named pipe".  In particular, there is no
dir_enter_pipe (file_t dir, string_t name), or
dir_enter_node (file_t dir, int maj, int min).

The reason is of course because we don't need special functions for these
"special files", they are all just provided by the filesystem directly or by
another filesystem.  The Hurd symlink() function in glibc sets a translator
on a file to make a symbolic link.  The translator is "/hurd/symlink TARGET"
of course.  And you can try to make an active translator like that, with 
settrans -a, and you will see a symlink translator running, and it will look
and behave just like a symlink!

However, and now there are a couple of issues to explain, you don't want one
process per symlink, nor do you want to have a symlink be stored as a
translator on filesystems which support symlinks natively (for cross
platform compatibility and maybe performance).  The latter is also true
for device nodes and fifo settings. 

To not have those special files stored as translators, but as native special
files, the filesystems shortcut the translator setting.  diskfs has special
support for this, see diskfs_shortcut_* variables and hook functions.
So a filesystem will usually recognise the "/hurd/symlink" translator
setting and shortcut it to a native symlink as provided by the
filesystem.  We allow it to do that, this is specifically
desired by our protocol.  

You can try it in another way: Copy /hurd/symlink to /hurd/mysymlink, and
set a translator with that filename.  You will not get the automatic
behaviour, instead you will get normal translator behaviour, because
only the server name "/hurd/symlink" is recognised in this way for
symlinks.

Likewise, the other way round, the Hurd servers will report translator
settings for symlinks, because this is what they are conceptually,
translated nodes.  Try it!  If you ever set a link with "ln -s", you can do
"showtrans" on the node and see the translator setting.

This is similar for other special files, like character and block devices. 
But we don't use those special files at all, so we don't have support for
them (that explains why there is no /hurd/chrdev and /hurd/blkdev).  Maybe
at some time we will.

There is a special case for symlinks in diskfs which makes it not start a
new translator for them, but to just read out the symlink target and do the
resolving of the target name internally (if the target is cross-fs, it will
give the unresolved rest as the retry name to the caller).  For fifos and
device nodes, those can not be implemented internally, so they are
implemented like real translators.  This is why you see a fifo process.

tar btw should notice /hurd/symlink translators and the others and treat
them as special cases, so it doesn't store them as translators but as real
symlinks.  This is so that you can pack a symbolic link into a tar file and
extract it on another Unix system (so it is desirable for cross platform
compatibility).  Currently tar doesn't support translators at all, so it
won't even notice.

The full list of such special translators is in <hurd/paths.h>:
/* Standard translators for special node types.
   These pathnames are used by the C library.
   UFS and perhaps other filesystems short-circuit these translators.  */
#define _HURD_SYMLINK   _HURD "symlink" /* S_IFLNK */
#define _HURD_CHRDEV    _HURD "chrdev" /* S_IFCHR */
#define _HURD_BLKDEV    _HURD "blkdev" /* S_IFBLK */
#define _HURD_FIFO      _HURD "fifo" /* S_IFIFO */
#define _HURD_IFSOCK    _HURD "ifsock" /* S_IFSOCK */

> However, it seems that a fifo translator was started (how?)

Although a fifo is short-circuited by the filesystem, it will be set, reported
and treated like a real translator.

> ludo@hurd:~/trans/tarfs$ settrans -g t
> settrans: t: Device or resource busy

It seems the fifo translator doesn't implement the go away RPC properly. 
Quite some of the translators don't do this, another example is pfinet.  It
would be nice if you could fix that ;)
 
Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus@gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/