Why? Device files have permissions on them.
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?]
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].
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...
> 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").
-- Raul- 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