lkml.org 
[lkml]   [1998]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: devlinks: an alternative to devfs
> As I understand it your devlinks won't point to an inode, correct?
> That means when you access /dev/fd0 the follow_link method for the
> inode_operations needs to be called. It is this follow_link method
> which is then doing the parsing. Then presumably you fiddle
> base->d_inode->i_op->default_file_ops, correct?

No. Just like device inodes, the devlinks would be the devices
themselves. The are reported and opened as usual devices. Just
the mechanism of obtaining the major/minor numbers, and potential
device parameters, are different. When the devlink is opened,
the file system asks for the driver by name, gets the device numbers,
and fills struct inode. follow_link would never be called for a
devlink, as it is not a symbolic link as soon as you set the dev
flag.

> You also need to support the readlink method, which will yield
> "fd:0,format=360" or some such. This leads to the confusing situation
> where:

No. As soon as it's a devlink, it will be reported as a device.
If you then want to know the string inside, you'd need a special
call.

> open ("/dev/fd0", ...) works but
> open ("/dev/fd:0,format=360") does not, even though
> % ls -l /dev/fd0
> lrwxrwxrwx 1 root root <date> /dev/fd0 => fd:0,format=360

No. ls -l /dev/fd0 returns exactly what it says today, or what it
would say in devfs. If you want the =>, you indeed need a modifies
ls, and possibly a modified

Regards,
Martin

\
 
 \ /
  Last update: 2005-03-22 13:41    [from the cache]
©2003-2011 Jasper Spaans