Just take a practical example: a graphical partition manager (gparted, qtparted, any partition manager in any linux installation program etc.). There you need to implement the partitioning using parted, most likely done using the operation stack parted provides, need to know about partition flags, need to convert data types and do your own structures representing the partitions in the UI etc. This is not really trivial, and can result in a more or less heavy implementation. Next to that, you need your program to check which file systems are supported (ext2/3/4, brtfs, xfs, ...), and need to implement the different options to check, format and handle each file system, not mentioning that the implementations on different platforms for the filesystem tools do not always match looking on the provided options. Now, every partition manager written nowdays does that on it's own, so we have dozens of different implementations of partitioning and file system formatting. UDisks should put this into literally one place where this kind of things are developed, and the end user application only makes use of the functionality udisks provides and "shows" the results. In my case, my implementation for a partition manager (Tribe) went down from ~6000 LoC to ~1200 LoC (ONLY the partitioning part, without the UI) using UDisks over DBus. And my implementation is not close to the length or perfection of other implementations (paradus has a ~13.000 LoC implementation, debian ~9.000 LoC, etc.). You still need operation stacks and similar, but you don't need to care about all the low-level calls and what-is-supported and what not, the permission handling (which udisks does using a quite nice policykit implementation). As a system administrator you probably will not need that in first place, but it easens up the work of application developers in need of disk/partitioning stuff [a lot]. Best regards, Georg <div class="gmail_quote"> On Tue, Nov 8, 2011 at 3:34 PM, Ivo Georgiev <<a href="mailto:ivo@linvo.org">ivo@linvo.org</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im HOEnZb">I think a D-Bus interface is much easier to implement in a program that needs to handle anything partition related. Plus, it's all a unified interface - getting data about devices, partitions and/or modifying them. In general, the problem of resizing file-systems and partitions is something that, in Linux, has no unified solution, To resize/check/create/modify a file-system you need to call the specific tool for the given FS. This is really tedious and annoying to implement, considering it is already implemented in other programs but the code is not reusable. When it comes to modifying the partition table itself, libparted is difficult to use. Having a unified system interface to do everything related to storage devices is really the way to go. By the way, how about implementing a Resize method in the device class if it is resizeable that abstracts Filesystem.Resize and Partition.Resize and calls them in the valid order or throws an error if the given dimensions overlap with other partitions. Also, a property that defines if the partition+filesystem can be shrinked/expanded/moved according to the FS type (e.g. XFS cannot be shrunk) would be nice. Also, that property should be influenced by which external tools are available (e.g. if e2fstools are not installed, this property of all partitions with ext* type will indicate you cannot modify them). On 08.11.2011, at 01:44, walt <<a href="mailto:w41ter@gmail.com">w41ter@gmail.com</a>> wrote: </div><div class="HOEnZb"><div class="h5">> On 11/07/2011 11:56 AM, David Zeuthen wrote: > >> ... >> The current code in master simply shells out to the parted(8), >> sgdisk(8) and sfdisk(8) tools to do the heavy lifting. I expect the >> implementation of Partition.Resize() to do something similar... > > Hi David. I'm very familiar with parted and friends because I use them > often, but I'm completely confused by why udisk should get involved with > those tasks when I (the user) can use the same tools directly. > > What is the problem that udisk would be solving by supplying the same > functions? Who whould be using udisk to do those tasks instead of > using the tools directly? I ask as a udisk outsider, so a very short > answer would be more than sufficient :) > > Thanks. > > _______________________________________________ > devkit-devel mailing list > <a href="mailto:devkit-devel@lists.freedesktop.org">devkit-devel@lists.freedesktop.org</a> > <a href="http://lists.freedesktop.org/mailman/listinfo/devkit-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/devkit-devel</a> _______________________________________________ devkit-devel mailing list <a href="mailto:devkit-devel@lists.freedesktop.org">devkit-devel@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/devkit-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/devkit-devel</a> </div></div></blockquote></div>