> 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?
I don't know the file system internals well enough to comment on this.
:-/
> 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
>
> "=>" is used by ls to show a devlink, rather than "->".
Good point. That is a confusing situation.
> It also requires a modified ls. You may also need to modify other
> programmes which have directory browsers. I guess GNU tar would also
> need changes.
I was trying to avoid that by implementing devlink as 'symlink +
magic bit', so that these programs would work without changes.
> > That's true. Devfs still needs more control mechanisms. If I set up a
> > chroot jail, I want to have /dev/null in it, but I don't want to have
> > my insmod'd printer driver popping up in there.
>
> # mount -t devfs none /gaol/dev
> # cd /gaol/dev
> # rm -f lp* sd* hd* tty* pty* ...
The problem happens when an hour later, root issues the fourth command:
# insmod lp
I want this to create /dev/lp0, but not create /gaol/dev/lp0.
I suggest again using a sysctl or devctl to mark "/dev" as
"a place where drivers create entries when they initialize".
Michael Chastain
<mailto:mec@shout.net>
"love without fear"