> 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.
Just HOW does having devfs in the kernel have an impact on all drivers,
apart from the source? Devfs as implemented now, has threee features for
people who can not accept how it does things.
1.) You don't have to configure it into the kernel at all (no code
compiled in, thus no effect; old-style devices are used)
2.) Devfs support is compiled in, but devfs isn't mounted (old-style
devices are used)
3.) Devfs support is compiled in, and devfs is mounted in backwards-
compatible mode.
You'd probably want option 1, to be sure nothing new pollute your pure
idea of devices.
Most distributions would probably compile devfs into the kernel, but
default not to mount it and have it an install-option.
> 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.
Have you had a look at the devfs patch to see how much it really
influences?
/David
_ _
// David Weinehall <tao@acc.umu.se> /> Northern lights wander \\
// Project MCA Linux hacker // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
-
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/