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
Which gives you a default name for the device. With /sbin/hotplug, simple
userspace policy, and symlinks in /dev, you can emulate the current device
hierarchy. So, you get a device naming solution that gives you only the
device names for the devices you have.
This approach also de-emphasizes the dependency on major and minor
numbers. If device nodes are created in kernel space initially, userspace
doesn't need to know what the major/minor is for a particular device. The
symlink to the device node is all that's need to operate on the device.
Without the need to coordinate between kernel and userspace, at least some
majors/minors can be dynamically allocated as the subsystems and devices
are registered with the core. (These can then be exported via files in
driverfs). (This is similar to the dynamic allocation of minor numbers in
the USB subsystem that showed up recently...)
Oh, and it's with a modern, clean filesystem, 1/5 the size of devfs.
Thoughts? Comments? Flames?
-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/
This archive was generated by hypermail 2b29 : Tue May 07 2002 - 22:00:30 EST