Re: devlinks: an alternative to devfs
Richard Gooch (rgooch@atnf.CSIRO.AU)
Fri, 9 Jan 1998 10:58:00 +1100
James Mastros writes:
> On Thu, 8 Jan 1998, Richard Gooch wrote:
> > > > So? The unlink() will cause a delete entry to be maintained in the
> > > > internal database.
> > >
> > > Oh, really?! So if I go into /dev and unlink a *nonexistent* name,
> > > and then an hour later I insmod a driver, that driver is *not* going to
> > > appear? That is a nasty bit of state. Also it means the people in
> > > /dev can't use it either, so it doesn't even work.
> > >
> > > I think you are missing the point. I am talking about insmod'ing
> > > drivers after the system is running and after the chroot jail is
> > > set up and in use, not insmod'ing at boot time.
> >
> > I mean that if you do:
> > # rm /gaol/dev/lp0
> > # insmod lp
> > # ls -lF /dev/lp0
> > crw-rw-rw- 1 root root 6, 0 Aug 30 1992 /dev/lp0
> > # ls -lF /gaol/dev/lp0
> > /bin/ls: /gaol/dev/lp0: No such file or directory
> >
> > That's what you want, isn't it? This assumes that you know which
> > devices you want to disable in your gaol.
>
> Umm... that may be what he wants (probably is), but it isn't what would
> happen. I belive that the VFS code checks for file existance and
> permissions (of the directory, except in non sitckybit directories) before
> calling sb->s_ops->unlink. I could well be wrong here.
What happens is that the lookup inode method is called first, so this
may be used to create a temporary inode which is then passed to the
unlink mathod. I suspect that returning a negative dentry in the
lookup method wouldn't work, since there is no inode to decrement the
link count for.
> > And, we can be even more clever than that. By using:
> > # mount -t devfs -o explicit none /gaol/dev
> > # mknod /gaol/dev/null c 0 0
> > # mknod /gaol/dev/zero c 0 0
> >
> > we can ensure that *only* dev/null and dev/zero will exist in the
> > chroot environment. In other words, you don't need to know which
> > devices *may* be possible. This is even better than pre-emptively
> > removing entries.
>
> Exactly, and this shouldn't be difficult.
Already done. Piece of cake.
Regards,
Richard....