On Thu, 2009-12-10 at 20:49 -0800, ran...@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 _______________________________________________ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
