udisks2 - How to get basic functionality we had in old udisks?

[Guy]

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 <genlist at faert.net 
> <mailto:genlist at faert.net>>:
>
>     On 10/30/2015 05:02 PM, .. ink .. wrote:
>
>         On Fri, Oct 30, 2015 at 12:51 AM, Guy <genlist at faert.net
>         <mailto:genlist at 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 at lists.freedesktop.org
>     <mailto:devkit-devel at lists.freedesktop.org>
>     http://lists.freedesktop.org/mailman/listinfo/devkit-devel
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/devkit-devel/attachments/20151116/a8b25d87/attachment.html>