> > 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.
>
> I'm sorry, but I fail to understand your reasoning behind this statement.
> Could you please clarify? How is a driver which presents a traditional
> major/minor number interface affected by the presence of a devfs (which,
> presumably, uses a different interface to the driver).
>
> > 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.
>
> A driver is different from what? Please clarify. I'm having great
> difficulty understanding how this paragraph applies to the one before it,
> and how it is supposed to refute danielt's statement. Where is the
> 'kitchen-sink mentality' to which you refer?
I think his point was, devfs isn't a driver, and he went on to
describe what a driver is. Point being, we are less concerned about new
drivers being added in since they don't tend to affect other drivers.
Stephen
-
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/