As promised, I let you know about my solution to circumvent the udisks2
problems. A small and ugly program for collecting the most important
information about block devices can be found here:
http://faert.net/jangdeblannen/udevblk.c
This solution is not free of problems neither:
- libudev is poorly documented. A small (very problem specific) tutorial
can be found on http://www.signal11.us/oss/udev/.
- Another good source for everything about block devices is the source
code of udisks itself (see file device.c). Without it, I would have been
able to put it all together.
- Something I learned from the udisks source code is that libudev by far
does not give us all the info we need. There are many things that need
to be done "manually".
- An example: Good old udisks told us the name of files associated with
loop devices. This information is queried directly from the loop device
driver, by using an ioctl call. The consequence is, that this info only
is available when running as root.
- Other data must be queried from the /sys tree.
- If ever something changes inside /sys or the loop device driver or...
then the code probably needs to be adapted :-( This really is bad news
for any high level application. udisks was the perfect single point for
adaptations. I still am angry when think about how easily they gave up
compatibility in udisks2!
I hope this is useful for others.
Best greetings
Guy
On 31.10.2015 19:02, Federico wrote:
@guy:
What about using libudev? Note that these are just my 2 cents, i don't
know how to achieve that with udisks2, sorry.
http://www.signal11.us/oss/udev/.
Federico
2015-10-30 19:00 GMT+01:00 Guy <genl...@faert.net
<mailto:genl...@faert.net>>:
On 10/30/2015 05:02 PM, .. ink .. wrote:
On Fri, Oct 30, 2015 at 12:51 AM, Guy <genl...@faert.net
<mailto: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
<mailto:devkit-devel@lists.freedesktop.org>
http://lists.freedesktop.org/mailman/listinfo/devkit-devel
_______________________________________________
devkit-devel mailing list
devkit-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/devkit-devel
