Re: [PATCH] 2.5.14 IDE 56

Martin Dalecki (dalecki@evision-ventures.com)
Wed, 08 May 2002 10:18:34 +0200


Uz.ytkownik Patrick Mochel napisa?:
> On Tue, 7 May 2002 benh@kernel.crashing.org wrote:
>
>
>>> /driverfs/root/pci0/00:1f.4/usb_bus/000/
>>>
>>>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
> this:
>
> The logical subystems (ide disks, networking, etc) would register with the
> device model core and get a directory in driverfs:
>
> /driverfs/class/ide/
>
> Devices would be discovered and get a driverfs directory representing the
> physical location of the device:
>
> /driverfs/root/pci0/07.2/
>
> 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:
>
> /driverfs/class/ide/0/
>
> 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:
>
> /driverfs/class/ide/0/2

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
documentation.

-
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/