On 05/26/2017 04:03 PM, John Ferlan wrote:
...
>> Was there ever thought to adding loadparm to the machine XML? What's the
>> reasoning to not have it there. If it's only valid for bootindex=1,
>> then it's far easier to check if the machine XML has it defined rather
>> than perusing the disk/network lists (which could be lengthy) only to
>> fine none. If the concern is some other arch allowing a different
>> bootindex to have loadparm, then the simple decision there is to have a
>> "loadparm_bootindex=#" value that would match the disk bootindex=#
value.
>>
>
> I am not sure what you mean here? By machine xml do you mean <os> xml?
>
Sorry I was too lazy to go make the cross reference near the end of the
day/review. Guess I was thinking more <os> related though...
I see in <os> there's a <boot> subelement which has a relationship with
the <boot> subelement for <devices>...[<interface>|<disk>]...
Yes, the <os> has <boot> subelement, but it can be tricky to specify the
order of the boot device.
I think I was just trying to make sure that adding <loadparm>
to
<devices> would make sense "in the long run" and what other
implementations were considered and not taken because of some drawback.
The per device boot subelement was added to simplify the boot device
order. That's why I thought it made more sense to add it to the per
device boot element. Also from a user's perspective it's easier to
specify the loadparm when specifying the boot order.
Given the description I've read and the implementation that
searches
either disk or network lists looking for bootIndex = 1, I wonder if the
<os> <boot dev='xxx' > should be modified instead. Was that
considered
- what were the drawbacks? Can bootparm conceptually be added/used for
a non boot disk?
I'm not requesting one way or another - I'd just like to be sure the
question is answered before perhaps someone else asks it now or much
later when this isn't so fresh in your mind.
John