* Re: sys/fs and sys/block
2003-03-05 8:39 sys/fs and sys/block Dominik Brodowski
@ 2003-03-05 17:05 ` Patrick Mochel
2003-03-07 12:02 ` Nikita Danilov
0 siblings, 1 reply; 3+ messages in thread
From: Patrick Mochel @ 2003-03-05 17:05 UTC (permalink / raw)
To: Dominik Brodowski; +Cc: linux-kernel
> I'm a bit surprised to find yet another top-level directory in sysfs --
> "fs". Wouldn't it be a bit more driver-model-conforming if there'd be a
> "bus_type block_bus_type" with devices like "hda", "fd0", "loop0", and each
> such block device registers a device like "hda1" for partitions of "bus_type
> filesystem_bus_type" (or "partition_bus_type"). And the device drivers for
> these devices are then the filesystems.
Ah, but sysfs is not just for driver model objects. It's for exporting any
object hierarchy. Its roots are in the driver model, and it just so
happens that the only other things to be represented in sysfs are closely
related to devices.
I will admit that the block and net subsystems should be redone as device
classes, since they clearly describe a type of device. I haven't had time
to make such a change, though.
> A few example on how this could look like in sysfs:
>
> sys/devices/pci0/00:07.1/ide0/hda/hda1
> sys/devices/platform/fd0/fd0
A while back we explicitly decided that this was a bad idea, since we were
trying to keep only physical (and some virtual) devices in that tree, and
partitions are clearly a different object type. However, there are other
object types starting to show up as children to the devices themselves.
This is completley valid given the semantics of the model, but it won't
work for at least block devices and partitions. Their lifetime is about
the same as the physical devices, but not tied directly to it. Therefore,
they need to be treated as such, with separate objects.
So, they get put in a different hierarchy. This could just as easily be
under the class/ directly as under the sysfs root.
Note that other class objects may need similar treatment. This also works
nicely, since it places all the objects related to the conceptual (class)
object under class/*, and leaves only devices under devices/.
> ? sys/devices/virtual/loop0 (a new "virtual" bus would allow us to register
> "virtual" and "dummy" devices)
This has come up before, and I'm still not ready to commit to a way for
doing this. It requires some more time and investigation that I'm not
able to dedicate right now. However, I will consider patches ;)
> sys/bus/filesystem/devices/hda1
> sys/bus/filesystem/devices/fd0
>
> sys/bus/filesystem/drivers/xfs
No! Filesystems are not buses. It's a completely different subsystem, and
should be treated as such. It's worse to overload the existing objects to
represent something they're clearly not than to just create new objects.
> Oh, and is the kobj in super_block (which was added in the same sys/fs
> patch) used anywhere?
>From the original author:
"Also, struct kobject is embedded into struct super_block. It is
naturally file system responsibility to register it (and may be some
other kobject's) at mount, and unregister at umount."
I wonder if it can, and should, be done automatically. Or, if we can just
use symlinks to point to the partitions, instead of creating a new object
at all.
Thanks for the questions,
-pat
^ permalink raw reply [flat|nested] 3+ messages in thread