Sarah,
Sarah Jelinek wrote:
>> Sarah Jelinek wrote:
>> ...
>>> ai_manifest.rng:
>>>
>>> -Seems like if we need the tag "partition_is_logical" it should not
>>> be optional.
>> I don't follow the logic here.
>>> What is the default in this case?
>> The default is 'false', that it is not logical.
>
> ok.
>
>>> I assume we create a primary partition?
>> yes, or extended
>>> Is there a better way to have this indicated?
>> Please explain what is wrong with the way it is indicated.
>
> 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.
>
>
>
>>> 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.
Thank you,
William
