Goals for 0.3.0

[David Zeuthen]

On Thu, 2004-07-22 at 15:55 -0400, Joe Shaw wrote:
> On Thu, 2004-07-22 at 21:25 +0200, David Zeuthen wrote:
> > There were some discussion about this some time ago and I proposed that
> > in the worst case you can always use the parents udi appended with
> > something otherwise unique or at least something that doesn't clash with
> > your siblings. By induction this provides unique UDI's [1].
> > 
> > Specifically for drives you can use partition numbers in lack of UUID or
> > label. Maybe even an MD5 of the first couple of sectors or something.
> 
> Yeah, but how do we make them unique across invocations of HAL such that
> things can reliable depend on them?
> 

We will have to be careful for starters; it's dependent on the bus/class
type exported by the kernel; so for the chain for storage devices we
have

 usb, ieee1394, pci    (pci since scsi_host can be a hw scsi host)
  scsi_host            append "-scsihost" (there is only one)
   scsi_device         append "-<lun>" (they are unique)
    block              append "-topblock" (there is only one)
     block             append "-block<uuid>" (is unique, otherwise
                                             label, otherwise partnum)

or something? 

But we do have to be careful, if <lun> is not unique then everything
fails to the ground[1]. In such scenarios it might be more safe to stop
appending in that part of the tree and just create a new udi that is
stable with what you have, e.g. disk serial number of md5 of sector 0
(which doesn't contain filesystem data). But we can still append beneath
that.

I guess the only way to find out is to go through and do it.

Cheers,
David

[1] : but for stuff like card readers these are unique; we use it as key
to media type e.g. compact flash
_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal