DBus method naming of upower/udisks

[David Zeuthen]

On Thu, 2009-12-10 at 20:49 -0800, randyf at sibernet.com wrote:
>    I don't mean to be disrespectful, but it doesn't surprise me that
> this is considered OS neutral.  However, the fact that "U" sits
> prominantly in the name implies that it is derived from 'udev': a
> Linux-only facility.

As I said here

http://lists.freedesktop.org/archives/devkit-devel/2009-December/000567.html

the U can mean whatever you want. The only relation udisks has to udev
is that it sits naturally on top of the Linux /dev manager and
infrastructure. Any modern OS should have similar mechanisms to udev -
if it doesn't then it's probably not a modern OS.

Maybe it's not clear to you, but it's not like udisks is supposed to be
_both_ a spec and a reference implementation because it's just not
useful to do (whereas for stuff like POSIX and D-Bus it might be useful)
given what kind of problems we are trying to solve. Which is: mostly
real ones.

So the names used in the ABI is going to stay udisks. Anyone can of
course reimplement this ABI on whatever OS they want but I think that's
a waste of time - just send patches upstream to the actual existing and
working code. Or you can just decide that udisks isn't interesting and
work on something else.

(Of course the udisks code right now is pretty Linux specific so a lot
of work will have to be done to factor things out. I'm OK with reviewing
patches for that - and if they don't surface, I'll just do it myself
when the time is right - pending mostly on having a good D-Bus library -
e.g. the GDBus that I'm working on merging into the GLib stack.)

>    Even 'LinuxMdStop' below is *not* OS agnostic., and suggested the
> btrfs interfaces below imply that "others should conform to Linux" (why
> not "there are interfaces for ZFS which might look similar to what btrfs
> will need" - though  this would imply a different OS centricity).

Strongly disagree. To repeat myself, LinuxMdStop() and associated ABI
refer to the Linux md(4) Linux-driver on-disk format. It is not
inconceivable _at all_ that other OSes can implement this - for prior
art in this area, see e.g. existing ext2 filesystem drivers for Windows
and OS X. Is it useful for other OSes to do this though? Probably not.
So their implementation will just return ENOSUP.

Also, and maybe this isn't clear either, but we're not going to play any
useless abstraction games here like we tried with e.g. HAL - e.g. we're
not going to have an abstract RAID interface and pray (upfront, even)
that it will cover both Linux MD, FreeBSD geom and whatever Solaris
provides. Because that's just not going to work.

Instead, we're just providing modern and useful D-Bus interfaces that
will allow apps to do what they need to do. Sure, this means multiplying
the work on the UI side [1] in each client but it also means that the UI
can be useful, actually work and actually provide features that people
want. And if you look at the gnome-disk-utility code it's already set up
so there's a ton of code-reuse going on.

[1] : you'd need one UI for Linux MD, another UI for Linux BIOS-raid,
another UI for FreeBSD GEOM, another UI for HW RAID for vendor X,
another UI for HW RAID for vendor Y and so on

Ditto for ZFS, btrfs and maybe even various iSCSI stacks. They will all
have different and specific interfaces. The only real common interface
we have is the UNIX block device - we can get away with this because
POSIX and other standards kinda specifies what a block device is und so
weiter.

Maybe down the road, if there's sufficient commonality, we can invent
abstract interfaces for e.g. RAID. I don't think that's realistic
though.

>    I would go further to state that unless that the primary
> contributors of these names or interfaces is not _actively_ using at
> least 3 different OSes (versions or relicants of one doesn't count),
> providing either claims or code to the common good as OS neutral, is
> a non-sequitor (and, dare I say, this is sounding more like the
> Windows Borg collective).

Also, I don't mean to be rude, did you just copy/paste this from a
text-book on software development? FWIW, your whole message strongly
suggests that you are pretending that doing a useful cross-platform disk
service is *easy* and that the way things work is that we design things
up front, committee-wise.

May I humbly suggest that you do some reality-checking because it's just
not how software development or the real world works. Especially not if
you are building on top of existing interfaces like we are doing here.
Also, lots of people actually suggest that such non-agile methodologies
(both in free and closed development settings) doesn't work at all.
_Especially_ it doesn't work this way in a free software setting where
we have around two (or more) releases of *multiple* OSes every year.

In fact, the main reason that we only offer limited ABI stability
guarantees is a direct consequence of realizing that we want headroom so
we can change the interfaces as we see fit.

No-one is saying the code is OS neutral - all that is claimed is that
the interfaces ideally would be OS neutral. Someone who cares about
non-Linux will have to step up and actually send patches to make this
happen. Maybe this involves breaking some udisks ABI but, hey, you know
what? I'm ready to do that. And with the way the project is set up, we
can do this.

Most importantly, and I'm repeating myself here, this actually includes
sending real patches instead of dreaming of abstract interfaces that
works on "at least 3 different OSes" [sic]. It just won't happen
automatically no matter how hard you're dreaming. Sorry if this comes
across as an insult but I do like to ask that you keep things real.

Hope this helps.

     David