On 10/30/2015 05:02 PM, .. ink .. wrote:
On Fri, Oct 30, 2015 at 12:51 AM, Guy <genl...@faert.net> wrote:
This leaves me with a strange feeling... can I rely on udisks2?
Probably not as you are not the target audience,look at "audience"
section in the following link
for more info: http://udisks.freedesktop.org/docs/latest/udisks.8.html
You can do all of these things yourself without udisks ridding
yourself of a dependency with
an unstable API.
You can get a list of partitions from parsing "/proc/partitions".
Let say you have a partition with a node address of "/dev/sda5", you can get
the starting offset of this partition by reading "/sys/block/sda/sda5/start" and
you can get the size of the partition by reading
"/sys/block/sda/sda5/size". Both
sizes are in sectors.
you can get pretty much everything you want by pocking around at
"/sys/block/" and you can
get a list of mounted volumes by parsing "/proc/self/mountinfo".
That's exactely what I didn't want to do: Fiddling a bit a everywhere
until I have all the info. And fiddling again after some updates...
I am not the target audience? Wrong! It looks as if I am *no longer* the
target audience, because in udisks I was! udisks2 breaks with the
elementary code of conduct, that a newer version must support previous ones.
Is it really that difficult to produce a list of {Vendor, Model, Serial
number, Size, Linux-device and Sector-size}?
Is it really that exotic to ask for this?
My conclusion: udisks2 serves as an example of how it should not be done!
rm -rf udisks2
To you mhogomchungu, many thanks for your answer! Just as you suggested,
I will have to look for another way. If I find one that pleases me I'll
post it here.
_______________________________________________
devkit-devel mailing list
devkit-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/devkit-devel