Goals for 0.3.0
david at fubar.dk
Thu Jul 22 13:11:34 PDT 2004
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 .
> > 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
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)
But we do have to be careful, if <lun> is not unique then everything
fails to the ground. 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
I guess the only way to find out is to go through and do it.
 : 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
More information about the Hal