> danielt@digi.com said:
>
> [...]
>
> > 90% of the objections to having devfs in the kernel
> > are easily solved with "well don't use it then".
>
> Wrong. Having devfs in the kernel has an impact on _all_ devices, if they
> use it or not. Giving the option has even more impact here than just
> forcing it one way or the other.
>
> A driver is something quite different: If the source is in the kernel or
> not has very minimal impact, a few lines outside of the driver itself.
> There is does make sense to apply kitchen-sink mentality, with core kernel
> functionality is just does not.
>
Which is why devfs is compatible with the current method
of doing things. Drivers that do not need to be changed for
other reasons do not need to be changed for devfs.
I have been able to do some really neat things with the
epca.c driver using devfs easily. The same actions
with the current architecture involve gross hacks and
/proc pollution. Being able to tell driver status at
a glance, identify boards and modules, all with just
the kernel portion of devfs and moving about 10 lines
of code around. No userspace daemons trying to work
magic through /proc files, just register the devices
with _names_ that reflect what they are.
It is wonderful.
As near as I can tell, arguments with respect to
"persistent device ownership" are fluff. I have
yet to see one detailed. Sure, I _could_ change
the ownership of /dev/fd0 so that a given group
of users can access it directly. I can also give
that group of users permission to access mtools
through sudo to manage floppies.
-- Daniel Taylor Senior Test Engineer Digi International danielt@digi.com Open systems win.
- 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.tux.org/lkml/