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
> 


Reply via email to