[dm-devel] [PATCH][RESEND+fixes] dm + sysfs

[Mike Christie]

Hi Joe,


> dm code.  The current code is structured to support different
> interfaces (eg. ioctl, dmfs).  I see sysfs as simply another user
> interface, albeit a read only one, so it would be nice if it could be
> written without embedding kobjects etc. in the core dm structs.  

I agree the patch's kobject use is invasive. This is becuase the 
mapped_device already has device model (kobject in gendisk) code, but 
the table and target code does not. alloc_disk/add_disk are wrappers 
around kobject_init/add. del_gendisk/put_disk are wrappers around 
kobject_del/put. Without my patch and without using the dm's interface 
infrastructure dm already shows up in /sys/block/dm-*. The kobject 
additions I made are just extending and continuing this in a manner 
consistent with the gendisk usage.

> reason you're finding this hard to do is that I never intended for
> people to run more than one interface at the same time, so there is no
> update mechanism to inform the interfaces of any changes initiated by
> a different interface.  Adding such a feature is not something I
> wanted to do, since it will end up defining what it is possible to do
> using a user interface, for example the ioctl interface supports 2
> namespaces for devices (name, uuid), whereas dmsfs supports an
> arbitrary number.  How should we map these onto each other ?

Sysfs is only trying to represent the dm layer wrt to the
2.6 device model. It is not concerned with interface specifics like the
namespaces that the ioctl or dmfs present to the user. My sysfs
additions are only trying to present the internal structure of dm and
how it relates to the other structures in the io stack.

IMHO sysfs and dmfs/ioctl should have two different responsibilities.
sysfs - presents a view of the system (like what the dm's status
infrastructure is doing).
dmfs/ioctl - creates, deletes, renames and modifies (table reloads) the
dm devices.

Sysfs should be used to compliment the dmfs and the ioctl interfaces.
The ioctl interface does not need the list, status, and deps commands
this info can be looked up in sysfs. To support a command like "dmsetup
(myuuid or nmyame) info" the ioctl just needs a command that takes the
name or uuid and returns the device's root sysfs dir. The userspace
app/lib can then get the info from there. This can be done in a
dm-ioctl-v4.c function by passing the hash_cell's md ptr to a function
in dm.c which returns the gendisk's (the kobject in struct 
mapped_device) name which was set in alloc_dev. This will keep the 
interface's namespaces private as it should be. For dmfs we could just 
use the same namespace to dm core lookup function and create symlinks 
into the sys tree to present device info.

 From this perspective where all interfaces are built on top of sysfs,
and it is replacing the status infrastrucure with a standard stucture
common to the kernel, would it be preferable to keep my kobjects with
the gendisk's in the core dm structs rather than moving mine and using
the callback design?

> Can you come up with a list of events that your sysfs interface is
> iterested in ?  eg. you are probably interested in a device rename, a
> table load etc.  Once we have this list we can maybe let the
> interfaces register callbacks for notification of these changes.

If the above arguments are too weak, I will send a list of events in the 
next mail.

> Hope this makes sense.

Yes, I understand your point of view. I am probably misinterpreting the
device model and sysfs and how it should relate to dm. Thanks for the
comments.

mike


Mike Christie
mikenc at us.ibm.com