Evolving storaged API
Jan Safranek
jsafrane at redhat.com
Tue Jan 28 08:54:56 UTC 2014
On 01/28/2014 09:13 AM, Marius Vollmer wrote:
> Hi,
>
> the dependency of storaged on UDisks is itching me a bit. It should
> work very well with it, but I think it should also work without it, I'd
> say.
>
> We are not far away from that goal, actually. Here is what I have in
> mind...
>
> - Add "Device" property to LogicalVolume. Then clients can work with
> logical volumes without UDisks.
>
> - Add PhysicalVolume objects, with "Device" etc properties and "Remove"
> etc methods. Make PhysicalVolumeBlock point to it instead of the
> VolumeGroup.
>
> - Change VolumeGroupCreate and AddDevice methods to take /dev/foo
> devices instead of UDisks object paths.
>
> - Add VolumeGroupCreateFromUDisksPath etc.
>
> - Add UdisksBlock properties to LogicalVolume and PhysicalVolume that
> point to the UDisks objects.
>
> - Have our own Job interface.
>
> - Just watch whether UDisks is running, but don't start it.
>
> What do you think?
Just a question, will it still be possible to _easily_ match UDdisks
object with storaged objects? Now they have the same object path, will
it stay the same? I find it pretty convenient from application point of
view.
Jan
More information about the cockpit-devel
mailing list