Hi Alex, (CCing c-d)
Alexander Eremin wrote: > On Fri, 2009-10-16 at 13:38 +0200, Jan Damborsky wrote: >> Hi Alex, >> >> I have looked at changes for 3136 and I have >> some additional comments - please see my response >> on c-d. > Agree, in this case we should consider about user choice - should > he use something like <label unlabeled disks>yes</> in manifest or > some another method.. I think this mechanism is to be delivered by another bug - as you mentioned this would perhaps fall under 6260. Speaking about bug 3136, I think its scope is only Target Instantiation. What I feel we should do is not to put label on disk by default - it should be controlled by the consumer of libti. Setting attributes in nvlist is the standard way how the information is passed to TI - please see following design document for the inspiration :-) http://www.opensolaris.org/os/project/caiman/files/slim_ti_design.pdf I might recommend to create new TI target - 'disk label'. This might seem as heavy weight solution for this particular issue, but as there is a plan to support installation on EFI labeled disks, I think it will be useful to have possibility to control those two operations independently (labeling the disk, creating VTOC). For instance, following attributes might be used to create 'disk label' TI target: TI_ATTR_TARGET_TYPE (uint32) = TI_TARGET_TYPE_DISK_LABEL TI_ATTR_LABEL_DISK_NAME (string) = cXtXdX TI_ATTR_LABEL_TYPE = (uint32) { TI_DISK_LABEL_TYPE_SMI, TI_DISK_LABEL_TYPE_EFI } More might be added later if it turns out they are needed. In order to correctly determine what is to be done, consumer will also need mechanism to find out what kind of label is currently on disk. Target Discovery is supposed to provide this information (TD_DISK_ATTR_LABEL attribute). I am not sure if it is going to fit all needs in that area, for instance if it correctly detects unlabled disks. If it does not, we could file bugs against TD. Thank you, Jan
