> On Fri, 8 Oct 1999 danielt@digi.com wrote:
>
> > On Fri, 8 Oct 1999, Horst von Brand wrote:
> >
> > Having _actually_ dealt with a non-devfs driver under devfs:
> > 1. I had to make 0(zero)(NULL) changes for the driver to work
> > with devfs. None. Nada. Not a line, character, or bit.
> >
> > 2. Once devfs was installed I was able to make significant
> > behavioral changes with many fewer lines of code than
> > those changes would otherwise have taken. Less debugging,
> > cleaner result.
> >
> > 3. It wasn't until several weeks _after_ I had hacked all of
> > this that I noticed that there were special functions
> > available for devfs that would have let me do _more_!
>
> Now what happens when devfs is in the kernel, and new
> drivers come out that only support devfs?
>
The devfs functions are largely compatible with the existing
functions. If it turns out that this is a potential problem
with adoption the functions can be reduced so that it _only_
supports the standard device registration methods.
It will simply use the name requested (the one that goes into
/proc/devices) and create the requested number of devices.
If it is in compatability mode it even shows the proper
Major/Minor pairs.
I repeat: I have been able to take full advantage of devfs
with a completely devfs unaware driver. The modifications I
made did not break the driver when devfs was uninstalled.
The changes in behaviour were only _visible_ with devfs, even
though they existed without it.
-- 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/