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

[Oliver Neukum]

Am Dienstag, 30. Juli 2002 00:21 schrieb Patrick Mochel:

> 1) devfs imposes a default naming policy. That is bad, wrong and unjust.
> There shalt not be a default naming policy in the kernel. Period.

Why not? Who really needs the ability to name anything in /dev ?
You can always use a symlink if you realy, realy want.

[..]
> devfs was already implemented in the wrong way in the first place. Instead
> of requiring modification to every driver, the devfs registration should
> have taken place in the subsystem for which the driver belongs to. In most
> cases (I won't say all), the driver already registers the devices it
> attaches to with _something_. The proper thing to do is not to create a
> parallel API, but one the subsystems can use. The subsystems already know
> most of the information about the device, they should use it.

I am afraid I have to disagree violently here.
A device on this level is a logical thing. It must not matter which subsystem it
is attached to. Furthermore, the subsystem cannot know what the physical
device actually does. That's what a driver does.

<snip comments on code quality>

> With symlinks back to the device's directory in the physical hierarchy
> layout. The user can see what devices of what type they have, and have
> access to their configuration items.
>
> It is that mapping (from logical to physical) that is really useful, not
> the other way around. Users probably aren't going to be poking around
> in the physical layout as much as they will be in the logical layout (but
> we keep all the attributes in one place with symlinks between them).

The problem is that a device without a mapping to a driver is a valid
state. In fact, this is how hotplugging scripts have to work.
 
> So why call include the devfs information at all? The SCSI people have
> been doing something similar for a couple of versions now. They export a
> driverfs file with the kdev_t value in it. Granted, they export it as one
> value, which is bad, but it's only the kdev_t number.

They export a kdev_t ???

	Regards
		Oliver