Goals for 0.3.0

[David Zeuthen]

Mmm, reading what I just wrote just doesn't make sense; some more
rambling

On Thu, 2004-07-22 at 22:11 +0200, David Zeuthen wrote:
> 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.
> 

We should always start with a new udi (e.g. don't append) for removable
media (discs, memory cards) and even coldpluggable devices (like
harddisks) since media and harddisk can and will be moved around.

Indeed it would make sense to have a property called info.is_detachable
that specifies whether the HalDevice can actually be physically detached
from it's parent HalDevice. Mmm, good thing I'm on a mission to clean up
the spec so we can get an overview [1]; I'm a little lost.

Cheers,
David

[1] : ideally we should have info.is_removable, info.is_hotpluggable and
info.is_detachable to specify the how "detachable" the device is wrt.
the parent.



_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal