Dave Miner wrote:
> Evan Layton wrote:
>> Evan Layton wrote:
>>> Joseph J VLcek wrote:
>>>> Evan Layton wrote:
>>>>> Joseph J VLcek wrote:
>>>>>> Evan Layton wrote:
>>>>>>> Evan Layton wrote:
>>>>>>>> Dave Miner wrote:
>>>>>>>> <...>
>>>>>>>>>>> I'd really like to figure out a means of not hard-coding the
>>>>>>>>>>> boilerplate stuff that you have in be_create_menu(), though.
>>>>>>>>>> I would to but so far I don't know of anywhere I can grab this
>>>>>>>>>> information from if there isn't already a menu.lst file. Any
>>>>>>>>>> ideas here would be a huge help.
>>>>>>>>>>
>>>>>>>>> There probably isn't since ict.py also has it hardcoded, and
>>>>>>>>> thus we should invent something so that the results of an
>>>>>>>>> initial install and this recovery are approximately the same.
>>>>>>>>> Something like a menu.preamble that could be copied into place
>>>>>>>>> might do the trick.
>>>>>>>> Hi Dave and Joe,
>>>>>>>>
>>>>>>>> What I have right now is a call to system() that calls the ict
>>>>>>>> to fill in the menu.lst. Then I fill in the BE entries and
>>>>>>>> figure out which BE is the currently active BE and use
>>>>>>>> system("bootadm set-menu default=%d") based on which be is
>>>>>>>> currently active. This results in a rebuilt menu.lst that
>>>>>>>> appears to be accurate. However this does require that I call
>>>>>>>> the ict to create the initial menu.lst file with the first three
>>>>>>>> lines which still leaves us with the hard coded lines in ict.py.
>>>>>>>> Should we place this menu.preamble file someplace and then use
>>>>>>>> it for both libbe and ict.py?
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>> -evan
>>>>>>>>
>>>>>>> I neglect to mention that I updated the webrev with the changes
>>>>>>> so far
>>>>>>> to use as a reference...
>>>>>>>
>>>>>>> http://cr.opensolaris.org/~evanl/5221/
>>>>>>>
>>>>>>> -evan
>>>>>>>
>>>>>> I think, since ICT is the single point of access to this info,
>>>>>> having a menu.preamble file is less important.
>>>>>>
>>>>>> If BE uses ICT and it is felt the menu.preamble is needed then the
>>>>>> only code that would need to change is ICT.
>>>>>>
>>>>>> So I think Evan should move forward with this implementation. If
>>>>>> others feel a menu.preamble has benefits then let's file a bug
>>>>>> against ICT to use the menu.preamble.
>>>>>>
>>>>>> Evan I noticed you took this off caiman-discuss. Guessing that was
>>>>>> by accident. I'm sending it back out to c-d.
>>>>>>
>>>>>> Joe
>>>>>>
>>>>> There was a sparc issue that I had failed to account for. I've
>>>>> fixed that and updated the webrev for that as well.
>>>>>
>>>>> Thanks,
>>>>> -evan
>>>>> _______________________________________________
>>>>> caiman-discuss mailing list
>>>>> caiman-discuss at opensolaris.org
>>>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>>>> Evan,
>>>>
>>>> Summary of our phone conversation:
>>>>
>>>> In looking at the webrev I got an idea. Why not create a function
>>>> which does both the attempt to open and if that fails then the
>>>> attempt to create. What I am envisioning is a open( read|create )
>>>> type of thing.
>>>
>>> Definitely a good idea. I've removed all this duplicate code and
>>> created be_open_menu that now does this. I also moved the error
>>> message mentioned below into this new function and corrected the
>>> message.
>>>
>>> I also realized while going through this that I was setting the
>>> default wrong in the menu.lst file. I was setting it based on the
>>> currently active BE and not the active on reboot BE which is what it
>>> should have been. I fixed this as well.
>>>
>>> I've updated the webrev to reflect these changes.
>>>
>>>> Also the error message, example on line 367, should be reworded
>>>> since if the open fails the code attempts to create the file.
>>>>
>>>> Hope this helps. Joe
>>>
>>> It definitely does help! :-)
>>>
>>> -evan
>>
>> As per our phone conversation I've added the comments around those
>> places that we call be_has_grub to state that this is being called to
>> check for grub support.
>>
>> I also added a warning message that will always be printed out when we
>> create the new menu file.
>>
>> I've updated the webrev to reflect these as well as any other comments
>> I've received to this point.
>>
>
> Sorry for the extreme delay in re-reviewing.
>
> be_utils.c 3167: MAXPATHLEN abuse; this isn't a pathname.
Yes that should have been BUFSIZ. I've changed it.
>
> Otherwise this is OK.
Thanks for looking it over again!
-evan
>
> Dave
>
>> Thanks!
>> -evan
>