Hi Sundar, thank you very much for your comments.
I have tried to address your questions relating to Target discovery Disk module. Jan Sundar Yamunachari wrote: > William, > > 1. Section 4.1.2.1: I have a question on td_get_next() and td_reset(). > Do have to call td_reset() after completely enumerated all the > items on a particular object type? Do I have to call tc_reset() before > making a call to td_get_next(). > > 2. The following enumeration functions are supplied for random access > td_errno_t td_get_slice_next(char *dev) > get next slice of partition (x86) or disk (sparc) and > make it current > > What is meant by random access here? Does it mean that I can get > attributes of any device by passing it as an argument? > > 3. Section 4.1.4: Is it possible to get the manufacturer of the disk > and added to the list of attributes? The GUI might want to display > that information to the user. I will add it. The disk module will report additional "string" attribute for this - TD_DISK_ATTR_VENDOR. > > 4. How do I know whether disk contains a label (VTOC or GPT)? How do I > know if it doesn't have a label? For now, there is only one disk attribute, which can directly provide you with information about disk label - TD_DISK_ATTR_GPT is set when disk contains valid GPT label. The information about other label types are now provided only indirectly: [1] When partitions are reported for x86 disk - it means that it contains valid fdisk partition table. [2] When slices are reported for particular disk - it means that disk contains valid VTOC label. [3] If disk does not have partitions nor slices - it might be supposed that it is not labeled. If it could be useful, I can think that we might add another disk attribute (let's say TD_DISK_ATTR_LABEL type "uint32") reporting label type: TD_DISK_ATTR_LBL_[VTOC | FDISK | GPT | NONE]. It might be used as bitmap, since I can think about the case when one disk contains more than one label - for example x86 disk might have fdisk partition table and vtoc stored within one of the fdisk partiton. In such case we should probably report TD_DISK_ATTR_LABEL = TD_DISK_ATTR_LBL_FDISK | TD_DISK_ATTR_LBL_VTOC. Might it be correct ? > > 5. We talked about providing content type of each partition. Where > will I get that information? I understand that TD_PART_ATTR_LSWAP will > tell me whether it is linux swap or not. It will be better to return a > content_type attribute and one of the values could be linux swap. The content type of partition can only be determined from TD_PART_ATTR_TYPE attribute, which contains partition ID. TD_PART_ATTR_LSWAP is only set for partitions with ID 0x82 containing valid Linux Swap configuration area - it is determined by algorithm looking inside the partition. You are right that in future we might have other functions which might confirm or further specify, what particular partition really holds and if this corresponds to the ID set for this partition. For this extension I agree, it would be better to have other than "boolean" attribute , which might hold these result of some heuristic algorithms looking inside the partition. For Dwarf, we have only one such algorithm implemented - for Linux Swap. For other partition types, there is only partition ID reported. > > 6. How do I get the mount_point of a slice? I will add another "string" slice attribute for this - TD_SLICE_ATTR_MOUNT. Thank you, Jan > > Thanks, > Sundar > > Sarah Jelinek wrote: >> Hi All, >> >> I posted new design documents for the Dwarf Orchestrator and Dwarf >> Target discovery pieces on the Dwarf project page. These are >> significantly different than the first drafts of the designs. >> >> If possible, please review and comment by COB 4/6/07: >> >> http://opensolaris.org/os/project/caiman/Dwarf/#Dwarf_Caiman_Design_Documents >> >> >> >> Regards, >> sarah >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://opensolaris.org/mailman/listinfo/caiman-discuss > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://opensolaris.org/mailman/listinfo/caiman-discuss
