Re: [PATCH] integrate driverfs and devfs (2.5.28)

Patrick Mochel (mochel@osdl.org)
Mon, 29 Jul 2002 12:33:40 -0700 (PDT)


Wow. I don't know whether to laugh, or to cry.

On Sun, 28 Jul 2002, Adam Belay wrote:

> This patch integrates driverfs and devfs. A summary is as follows:
> - create new interface directory and move interface.c
> * I intend to add more to this directory later
> - add devfs entry list
> - add devfs related functions
> - create devfs interface
> This patch is intended to be as non intrusive as possible. Therefore
> it doesn't modify devfs directly but instead creates a layer above it.
> This is due to the fact that if devfs was modified it would break
> every driver. Eventually we have to decide when and how to
> integrate it directly, This patch will provide the necessary
> infrastructure. Please Apply.

Not a chance. I refuse to apply any devfs interface layers to the device
model core, or any devfs-specific members to the device model data
structures. And, that's just on principle.

As for technical reasons, why on earth would you want to do this in the
first place?

We've collectively decided that enforcing device naming policy in the
kernel is the Wrong Thing To Do. devfs does this; and your patch furthers
the pain.

Besides, look at the interace. Tell me devfs_register is not horrid. 8
parameters is rediculous, and you want to add another one? And, change
every driver?

I won't touch devfs, as it's unmaintainable. I won't even look at it,
because it's unreadable. But, if you really want to build a bridge between
the two, I would suggest looking at a way to collapse some of the data
structures and the calls. devfs_register (or the like) should take 1
structure with all the information it needs in it. Most of that data you
can derive from other places (like a higher level). In fact, IMO, it
should be the higher level that is doing the registration of the devices,
not the individual drivers themselves.

I appreciate the effort, but I don't support it. We should soon have a
working device class model, which is where you'll start to see devfs-like
concepts handled in a sane way. Please look there for ideas, rather than
devfs.

Thanks,

-pat

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/