[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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 us ibm com






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]