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.
Otherwise this is OK.
Dave
> Thanks!
> -evan
