Hm. OK. That's something that I could do with devfsd. However, it
still seems to me that loading a driver should never compromise your
system. If it does the driver is broken.
> But, you say, people were talking about a user-space daemon which
> can create device files on the fly? Well, it's easier to upgrade
> that user-space daemon (to enhance its policies for dealing with
> permissions) than it is to update kernel space. [I hope you don't
> want people to be stuck waiting for linux 3.0 to deal with issues
> revealed as devfs gets deployed more widely?]
Fine. That's what devfsd does for you. Grab it and have a play.
> But, you say, devfs can have a user-space daemon? Sure, but how
> about taking devfs and turning it into something that has a robust
> split between kernel space and user space? At the moment, the only
> bits of devfs that only work in kernel space are:
>
> (1) dynamic allocation of major numbers [just report them in
> /proc/devices].
> (2) callout (user-space-handler) for file not found [which would be much
> more useful in vfs than in devfs].
>
> Ok, I'm not intimately familiar with devfs, and maybe there's other
> logical services in devfs that just have to be in kernel space [but at
> the moment I don't see it].
Well, I cover the reasons in the FAQ. One other reason I should get
around to adding: security. I expect many systems will not want to
change device permissions (the drivers provide sensible defaults). In
that case if some random hacker frobs the permissions on /dev/sda*
then the next reboot gives you back the default (safe) permissions.
> But making new device nodes isn't a performance critical task, so
> it makes sense to make it work using a series of sensible interfaces
> rather than as some application-oriented piece of work wedged into
> the kernel...
Creating device nodes with devfs is microseconds. With a daemon you
are looking at milliseconds (depending on what else is happening on
the system). That's a large difference.
> > Also, a device driver should fail safely if a piece of hardware is not
> > installed correctly. Further, a system should still be safe/secure
> > if a module is loaded, otherwise the driver is broken. Just because
> > a module is loaded doesn't mean that some random user can open the
> > device node and frob it.
>
> Ok, but now you've lost convenience against a user-space solution
> (where you can decide that new scsi disks on controller 1 will show
> up group writeable by group "disk1").
So use devfsd. But don't toss out the virtual FS because it still has
advantages. Not everybody is going to want a devfsd or something
similar (they will stick with the driver defaults). Devfs is lower
maintenance for these people.
Stuffing around with initrd, RAMDISCs and tricky boot scripts in order
to boot with a read-only FS or nun-Unix FS is conceptually difficult
and is prone to breakage. It is *fiddly*, whereas devfs is
conceptually clean and robust.
Finally, with devfs there is no need to co-ordinate the kernel sources
with the contents of /dev which is a management bonus. Having to
register a major number is an extra hoop that device drivers have to
jump through.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html