On 01/28/2014 09:13 AM, Marius Vollmer wrote:
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
We are not far away from that goal, actually. Here is what I have in
- Add "Device" property to LogicalVolume. Then clients can work with
logical volumes without UDisks.
- Add PhysicalVolume objects, with "Device" etc properties and
etc methods. Make PhysicalVolumeBlock point to it instead of the
- 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