Hi, On Fri, Jun 25, 2010 at 5:11 PM, Baybal Ni <nikuli...@gmail.com> wrote: > Let me support Maxim. First of all, such thing as a hardware > configuration is highly non uniform. We have real scsi hdd and > cd-roms-rams and other exotic scsi machinery, pci ssd, SX8 and similar > desktop sata controllers that doesn't export normal block sata > devices, real memory cards controllers and so on. And we also have > weird power management in some disks. You simply can't hard-code them > all. Doing this, I think we will just come to the point, from where we > were coming from, this way. It doesn't matter whether we would be > having broken fdi hardcoding thing, or just simple hardcoding.
I'm sorry but I'm having trouble parsing your message - I'm not really sure what you're saying except something like "yeah, this storage stuff is hard, let's make things better and export a lot of information and interfaces". Which really isn't news to anyone. You also seem to not be aware that udisks is actually already reporting a lot information (sas topology, wwn, drive type, media type, md raid, lvm, dm-multipath etc etc) and high-level interfaces (polling, SMART, PM) which seems to be in line with your request above. FYI, we also go to great lengths to use the information in the udev database for this - lots of the enhancements in udev's ata_id, scsi_id and cdrom_id stems from the needs of udisks. As Martin nicely explains, we have to get all this information from _somewhere_ and deriving it all from only udev rules is of course insane - especially since some of it is the result of computations and expressing such things in udev rules is just not very convenient (such as Device:DriveIsSystemInternal). And if you had read the code this would be crystal clear. The code is this way because we learned the lesson already with HAL that too many options (and too little hard-coding) can be expensive to maintain. So, yeah, this breaks Maxim's driver for xD mediacards insofar that he needs to change udisks, gdu and gvfs source code. Sorry, but that's just too bad. What is going to be the outcome? Maybe (probably not) that we'll just add more hard-coded entries to the table (it's not like new media formats emerge every two months - in fact, everything that isn't SD is probably going to die anyway) or maybe we'll throw some options at the problem so Maxim (and people like Maxim) can simply add udev rules. We'll deal with that once Maxim actually files bugs about it instead of sending mails saying everything should be customizable. Anyway, as I said earlier, the way to move forward is to report concrete issues (defects, features, anything) in the bug tracker and then either deal with the request there by either adding a feature or explaining / educating why things work the way they do or why the feature etc. does't belong in this layer (udisks) of the stack. So, in conclusion, wishing/complaining about things and making generic statements like "we shouldn't hardcode stuff!" or "we should make something awesome!" on the mailing list isn't going to help no matter how enthusiastic you may be - sorry! Instead, go file bugs at https://bugs.freedesktop.org/enter_bug.cgi - thanks! David PS : in Maxim's particular case I think we already have the infrastructure in place for this - Maxim should be able to just set ID_DRIVE_FLASH=1 for now cf. the udisks(7) man page: http://hal.freedesktop.org/docs/udisks/udisks.7.html Sure, it would be nice to have ID_DRIVE_FLASH_XD. File a bug. _______________________________________________ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
