GNOME Bugzilla – Bug 581742
port from HAL to DeviceKit-disks
Last modified: 2009-07-10 14:04:26 UTC
DeviceKit-disks has been proposed as an external dependency for 2.28, it would therefore be great if brasero could be updated from hal to DeviceKit-discs. I am filing this early on so you have all your time to look at the API and, if necessary, discuss enhancements and additions with David Zeuthen.
That was on my TODO list for a near future =).
Ideally Brasero would just rely on GIO for disc detection and not care about DeviceKit-disks one bit - if needed, we can add new G_DRIVE_IDENTIFIER_KIND_* G_VOLUME_IDENTIFIER_KIND_* defines to GIO (reflecting things like it actually is a optical disc or something is an actual optical drive) and then make the volume monitors we support (hal, gdu, unix) set this.
It would be great if you could do this. Especially since brasero also relies on GIO for other operations like mounting, ejecting, ... Just for the record, I had already asked to have such a thing (I mean something to identify the device type through GIO) in the past (once on IRC) but I was told that it was hard to do such a thing for all backends. So I'm glad it's now possible.
(In reply to comment #3) > It would be great if you could do this. Uh, I'm not sure I just signed up to do this work for you ;-) - but I'd be happy reviewing patches and discussing the best way to provide you with what you need. > Especially since brasero also relies on > GIO for other operations like mounting, ejecting, ... > Just for the record, I had already asked to have such a thing (I mean something > to identify the device type through GIO) in the past (once on IRC) but I was > told that it was hard to do such a thing for all backends. So I'm glad it's now > possible. I'd suggest - Figuring out what you need from GIO - Filing a bug against GIO asking for this and then we can take it from there (I already read all GIO and GVfs bugs). If we decide GIO is the right place for this (and, I, for one think it is) then the next step would be to - Write patches for GIO and the local Unix volume monitor - Write patches for the HAL and GDU volume monitors in GVfs but first things first.
David, sorry for taking so long to answer. Too bad you you didn't sign up ;). I was probably a bit too hopeful. I won't have much time to work on GIO in the coming months as work, brasero and the holiday will eat much of my time. But I'd be happy to open bugs, discuss, enhance, and perhaps provide patches according to my capabilities. Just not now. As for the port itself, I've started to do it. As a first step, I'm trying to use GIO wherever I can. Speaking about which, what I'd miss from GIO is mainly (I'll open bugs when I'm ready to work on them) a way to differentiate optical drives from other ones. As for DeviceKit-discs itself (and therefore GIO later) what I miss at the moment is a way to differentiate burners from regular optical drives (and also the types of discs it can burn). I can do it when there is a disc inside as brasero can use MMC commands; but when the drive is empty it's not possible anymore. Now, I noticed that there isn't any drive lock/unlock method any more in DeviceKit-discs. Am I correct? I think that was useful as a way to tell file managers or other apps that for example a disc was being burnt and that it wouldn't be a good time to mess with it or also to prevent the user from removing a disc. But at least I can do that latter part (lock for the user) with MMC commands (again provided there is a disc inside). Finally, I still hesitate to kill all the code for HAL since other OSes rely on HAL at the moment and I was wondering if they would adopt DeviceKit-* as fast as linux will? I can make both code live together for a while. Also for some OSes I'd need more information from DeviceKit-discs like bus_target_lun (FreeBSD, Open Solaris), and block device path (for Open Solaris) among other things.
For while we should maintain both HAL and devicekit. We should get this done for 3.0 it seems a bit late for 2.28
Brasero is now HAL free in master; and even better, it only relies on GIO as it turns out that a drive without a medium inside can be opened and therefore libbrasero-media can send MMC commands. That doesn't mean I won't file bugs (and provide patches hopefully) for GIO to improve some things. The only question is if support was preserved for FreeBSD and OpenSolaris but if issues comes up I'll fix them (I notified the people who sent me patches to support these OSes).