Is udisks worse that HAL?

[David Zeuthen]

Hi,

On Fri, Jun 25, 2010 at 5:11 PM, Baybal Ni <nikulinpi at 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.