Re: [PATCH] 2.5.14 IDE 56
Martin Dalecki (email@example.com)
Wed, 08 May 2002 10:18:34 +0200
Uz.ytkownik Patrick Mochel napisa?:
> On Tue, 7 May 2002 firstname.lastname@example.org wrote:
>>>and it wouldn't be impossible (or even necessarily very hard) to make an
>>>IDE controller export the "IDE device tree" the same way a USB controller
>>>now exports the "USB device tree".
>>>For things like hotplug etc, I think driverfs is eventually the only way
>>>to go, simply because it gives you the full (and unambiguous) path to
>>>_any_ device, and is completely bus-agnostic.
>>>But there is definitely a potential backwards-compatibility-issue.
>>One interesting thing here would be to have some optional link between
>>the bus-oriented device tree and the function-oriented tree (ie. devfs
>>or simply /dev). For example, an IDE node in driverfs could eventually
>>hold symlinks to the entries it provides in /dev when using devfs (or
>>just provide major/minor when not using devfs).
> I agree with such a concept, but as Linus said, it should go the other
> way, from the functional interface to physical interface. There are many
> details involved in doing such a thing, but it should work something like
> The logical subystems (ide disks, networking, etc) would register with the
> device model core and get a directory in driverfs:
> Devices would be discovered and get a driverfs directory representing the
> physical location of the device:
> Note that no drivers have been bound to the device. When the driver is
> bound, it registers the device with the subsystem, passing in a
> subsystem-specific structure. These can be made to point in some way to
> the generic struct device of the device (from which the physical path can
> be inferred).
> When this happens, the subsystem creates a directory underneath its
> driverfs directory, so you get:
> And, a symlink is created to point to the directory in the physical path.
> As the driver discovers partitions on the device, it can create special
> nodes in its class directory.
> At this point, userspace can be notified (via /sbin/hotplug). That can
> create symlinks in /dev to the nodes that were just created, emulating
> current /dev behavior.
> So, what does this do? To an extent, it reengineers the funtionality of
> devfs. I'll be the first to admit it. However, it centers less around the
> filesystem, and more on the device model core.
> Most devices already register with their subsystems, so having the
> subsystesm pass device info onto the core is relatively easy.
> As partitions are discovered, you get paths like:
Just a side note...
Please please name it /devices/ Some old boys like me (age 30)
can gain from similarities with some quite common "legacy" systems.
We don't have to "invent" for the sake of it.
And /devices/ is the way I have named it in the corresponding
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/