sys/fs and sys/block

sys/fs and sys/block

[Dominik Brodowski]

Hi Pat,

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. 

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

? sys/devices/virtual/loop0  (a new "virtual" bus would allow us to register
				"virtual" and "dummy" devices)

sys/bus/filesystem/devices/hda1
sys/bus/filesystem/devices/fd0

sys/bus/filesystem/drivers/xfs

sys/bus/block/devices/hda

Oh, and is the kobj in super_block (which was added in the same sys/fs
patch) used anywhere?

	Dominik

Re: sys/fs and sys/block

[Patrick Mochel]

> 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

Re: sys/fs and sys/block

[Nikita Danilov]

Patrick Mochel writes:
 > 

[...]

 > 
 > >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 (the original author) think it is cleaner to leave initialization and
registering of this kobject to the file system back end. For example,
there is no obvious generic way to generate names for such objects, etc.

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

Err. Not sure I understand. kobject representing file system instance
would probably have completely different set of attributes than
underlying partition object. Then, there are !FS_REQUIRES_DEV file
systems.

 > 
 > Thanks for the questions,
 > 

Nikita.

 > 
 > 	-pat