> > [...]
> > > 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.
> 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).
That is the point: There are _two_ interfaces to the driver. As a driver
author I must make sure _both_ work, so I must study both; I'll have to
compile four kernels (devfs/module) just to check that it doesn't break. I
must check that I don't hijack a major number, and that I don't take over
the device name for something else (this has to be done in the driver, if I
understand a recent post correctly). I must set up a default permission in
the driver, and also add it to MAKEDEV.
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513- 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/