On Thu, 10 Dec 2009, David Zeuthen wrote:
> On Thu, 2009-12-10 at 09:09 +0100, Martin Pitt wrote:
>> udisks already uses org.freedesktop.UDisks, and I expect upower will
>> change similarly.
>
> Right - and I think udisks, it being the project name is pretty OS
> neutral so I don't see any problem in using it in public interfaces. I
> also don't think we have any Linux specific bits in the interfaces.
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.
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).
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).
IM(very)HO, the fundamental problem with Devicekit (and friends,
including UDisks and UPower), is that the name of the provider is defined
*instead of* the name of the desired service. If there is *really* an
intent to be OS neutral, then describe first the service that is desired
(i.e. power, suspend, halt, etc.), and let an arbitrary provider handle
this service.
So, going back to what Jedy may have started to suggest (and focusing on
a single service: power), the *common* service that *ANY* (pardon the
shouting) OS will implement is "power". This would, in it's most basic
form, include "halt/shutdown", "restart/reboot", and "suspend". No matter
what OS or hypervisor, I believe that these are the primary three states
of "power" that will be implemented by all. These would be best presented
in a DBus name as:
org.freedesktop.power
with the addition of subordinate services:
org.freedesktop.power.halt
org.freedesktop.power.restart
org.freedesktop.power.suspend
It would be not only trivial for any provider, including UPower, to be
the sole (which also, IMHO, is key to any OS) provider to these services,
without a definition as to _how_ these providers should perform this
service. Given the above, there could be any arbitrary application (say,
GPM) that could give the user a common view into how to manage *any* OS
(including the dreaded Redmond OS). This is what I believe to be an OS
neutral view.
Now, I grant that this is a hard problem to solve, but it should always
start with "what is the problem we are trying to solve", rather than "what
is the tool we need to use to solve the problem".
rf
>
> Note that method names such as LinuxMdStop() isn't really related to
> "Linux, the kernel" or "Linux, the OS" - instead it's related to the
> on-disk format of (Linux) MD software raid and associated tools (e.g.
> mdadm(8)) and drivers (e.g. md(4)). Ditto for things like LuksLock()
> referring to LUKS (Linux Unified Key Setup).
>
> Presumably non-Linux OSes (or non-Linux kernels) could implement both
> Linux MD-RAID and LUKS - if not, implementations can just return the
> NotSupported error.
>
> FWIW, we can always add similar interfaces for e.g. FreeBSD geom or ZFS
> or whatever - FWIW, I'm planning to add interfaces for better btrfs
> integration - might look similar to what ZFS will need.
>
> Thanks,
> David
>
>
> _______________________________________________
> devkit-devel mailing list
> 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
