Hi William, Thank you for taking the time to provide such a detailed response....
>> >> It isn't wrong. That's not my point. It seems to me that the >> "optional" part of this tag makes it unclear that the default is >> false, or that it is even there. In looking at the code in >> auto_parse.c, we look for this, and then search to see if it is set to >> "true". Maybe this is due to the fact of the way the default settings >> work in xml and with our manifest server. Seems to me, it existence, >> or not, is the thing that tells us if it is set. Setting an optional >> tag with a boolean value seems counterintuitive to me. > I see. There is another method available. An RNG element can be > defined as <empty/> in the schema, so that if an instance of it appears, > ManifestServ returns an empty string, otherwise nothing. So if the > definition were changed to: > <optional> > <element name="partition_is_logical"> > <empty/> > </element> > </optional> > > And it appeared in the manifest as: > <ai_device_partitioning> > <partition_action>create</create> > <partition_is_logical/> > ... > </ai_device_partitioning> > > Then ManifestServ can find them. But, it won't work in this case, since > of the known ManifestServ inability to return associative arrays - there > must be default values. Read on... >> >> In looking at the way we defined this in the AI schema, we ask the >> user to specify if a partition they want to create or use is a logical >> partition, correct? > Yes >> Which means we should have an extended partition that we create this >> logical partition on, correct? > Yes >> If this is the case, the extended partition definition in the AI >> manifest, if this was required, and then any associated logical >> partitions would be an explicit way of indicating that the partition >> is logical. > Good point. Here is one way to do it recursively. In ai_manifest.rng, > within the <define name=ai_device_partitioning_contents">, add: > <interleave> > <zeroOrMore> > <element name="ai_logical_partition"> > <ref name="ai_device_partitioning_contents"/> > </element> > </zeroOrMore> > </interleave> > > So, for example, to make an extended partition of maximum size, then put > into it: > - a 10G FAT32 partition followed by > - a Solaris partition into it of maximum size: > <ai_device_partitioning> > <partition_action>create</partition_action> > <partition_type>EXTDOS</partition_type> > <partition_size>max_size</partition_size> > <ai_logical_partition> > <partition_action>create</partition_action> > <partition_type>FAT32</partition_type> > <partition_size>10</partition_size> > <partition_size_units>g</partition_size> > </ai_logical_partition> > <ai_logical_partition> > <partition_action>create</partition_action> > <partition_type>SOLARIS</partition_type> > <partition_size>max_size</partition_size> > </ai_logical_partition> > </ai_device_partitioning> > This works and the logicals would be retrievable searching for > "ai_device_partitioning/ai_logical_partition/<element>". > To do this, auto_parse.c:ai_get_manifest_partition_info() would have to > be parameterized for logicals vs. primaries/extended. > > If you don't like the recursive aspect, it can be avoided. > >> How do we handle the creation of a logical partition without the >> corresponding extended partition? > The user must have already created an extended partition to create a > logical partition, otherwise, an error is signaled and the installation > fails. >> Perhaps we don't create logical partitions in AI? > Yes, we can. >> It isn't clear to me in the code. > I will document this more clearly. > > BTW, Deleting partitions would still not change for logical partitions. > Currently no matter whether the partitions are primary, logical, or > extended, you can only delete by partition number, starting offset + > size, or starting offset. You could embed delete actions in > ai_logical_partition or not. > >> All of that said, it is ok the way it is. > Please let me know if you think this embedded <ai_logical_partition> > approach is better. I like the ai_logical_partition approach as you note above better. It seems logical to me and a better user interface. In case the user doesn't define a logical partition for the extended partition they are creating, would we create 1 logical partition the whole size of the extended partition? >> >> >> >>>> disk_parts.c: >>>> >>>>> 440 pinfo = committed_disk_target->dparts->pinfo; >>>>> 441 for (ipar = 0; ipar < OM_NUMPART; ipar++, pinfo++) >>>>> 442 if (is_used_partition(pinfo) && >>>>> 443 pinfo->partition_type == SUNIXOS2) >>>>> 444 return (ipar >= FD_NUMPART); >>>> >>>> Can't we check the pinfo->partition_id here for seeing whether this >>>> is an extended partition? >>> This function checks for logical partitions. Assuming there is no >>> error in the way the struct is populated, an extended partition can >>> never be a a logical partition. >> >> Right.. I get that. My point was that at this point we have the >> pinfo->partition_id value populated in the structure. Instead of using >> a separate variable, "ipar" can't we return the pinfo->partition_id > >> FD_NUMPART? > Yes - will change this, or use the new TD value for > extended/logical/primary instead. ok. thanks, sarah ***** > Thank you, > William
