[...]
> > 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.
> Interesting.... my response:
> 1) The interface is basically the same. The kernel hands you data, you
> hand it to the device. The only difference is in the registration
> procedure. Sounds like a very simple (and small) case to add you your
> coverage testing procedure. You do have a coverage testing procedure,
> don't you?
There _is_ a difference, I'll have to make sure I handle both (quite
different in purpose and needs) interfaces right. Extra work for all
developers for a very tiny gain.
> 2) You must always check to be sure you don't hijack a major number,
> regardless of devfs or not.
Not my point, I was saying that I must now _also_ take care of not
hijacking a name. But you don't have to mess with names if you don't use
devfs. What if I decide to set up a full chinese version of Linux, with
chinese device names? Now I can't even begin of thinking in using the stock
kernel...
> 3) How hard is it to pick a default permission for a driver? I mean,
> really... how hard is it? If I'm being careful, it only takes me about
> 45 seconds to decide on default permissions. How long does it take
> you? And, as in #2, you have to deal with MAKEDEV regardless of devfs
> or not.
For me alone it's perhaps 15s. For the computer labs around here it it will
probably need tuning on a lab-by-lab basis. For our servers they might well
be different. Don't forget this cute firewall box over there, with yet
another set... let's say half a dozen different kernels in all. The cost in
maintaining that set up to date is far larger than any cost involved in
managing devices by hand. Besides the fact that a misconfiguration will
have to be solved by rebuilding the kernel and rebooting.
-- 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/