New Boot Loader Menu

[Devin Teske]

Oops…

This time with the attachments (below).

NOTE: Don't forget to diff each one to see how we go from what's in HEAD today to each other demo
NOTE: vimdiff works better than diff, because it can highlight the differences *within* each line (showing a more succinct pattern of changes).

On Oct 8, 2012, at 10:21 AM, Devin Teske wrote:

>>>> Bonus points if you can make it easy to add a submenu via
>>>> loader.conf.
>>>> 
>>> 
>>> Done. There's zero difference in configuring menus in a "menu.rc"
>>> file than in "loader.conf" file.
>> 
>> Ok, different file, same idea. Can you post some sample menu.rc code so
>> we can get an idea of what "easy" means to you?
>> 
> 
> Gladly! Thank you for asking!
> 
> I'll post the 4 different "menu.rc" files that I am planning on demonstrating this Thursday at BAFUG.
> 
> Please find attached the following files (with accompanying descriptions below):
> 
> menu.rc.1.current-head
> This is what is in HEAD, CURRENT, and RELENG_9 **right now**
> 




> NOTE: Each of the following menu.rc examples *require* the new patchset that I'm sending through my mentor(s) to import to FreeBSD. We currently can't utilize _any_ of these features without the addition of "menusets.4th" (for example; among other changes).
> 
> menu.rc.2.submenu-head
> This is the menu.rc file that replicates the images posted at the beginning of this thread.
> Though, currently, I'm thinking I ought to craft a new menu.rc to show what Alexander Leidinger proposes.
> 




> menu.rc.3.submenu-cycler
> This menu.rc shows things that DruidBSD offers (but FreeBSD cannot). In other words, don't get too exciting about the *actual* menu items, get more excited about "what the menu can do" by this example. This example goes to show that (if we need it), we can accommodate "cycling" menu items (where a single menu item on a single stateful menu can exhibit a total of 10 usable states). These menu items "cycle" -- meaning when you reach the last configured item, it cycles back to the first. The text for these cyclic menu items (just like toggle menu items) are completely arbitrary (explaining that the "1of2" and "2of2" etc. text is configurable).
> 




> NOTE: The next example consists of two files. The menu.rc _and_ a very small devicemenu.4th file which serves as a stand-in for C callbacks. In other words, the code that is in the accompanying "devicemenu.4th" is actually mimicking what *ought* to instead be a series of C callbacks exposed to the FICL layer from something like base/head/sys/boot/ficl/loader.c
> 
> menu.rc.4.submenu-dynamic
> devicemenu.4th
> 






> This menu.rc shows how you can configure a menu that has not only dynamic menu *items* but that whole menus can be dynamic themselves (the menu items themselves are dynamically generated at runtime).
> 
> To make a dynamic menu, you have to back it by some runtime code. In this example, I've backed the callbacks with Forth code, but ***you don't have to*** and in-fact, my plans are to have these callbacks instead be provided by the POSIX C layer, namely base/head/sys/boot/ficl/loader.c (as one place where the C code exposes FICL constructs -- which ultimately are to be passed into the menu as a callback, configured via appropriately-named environment variables).
> 
> What's imperative to see in the demo of these 4 menu.rc files is that no Forth needs to be changed. Just drop in the appropriate menu.rc and reboot (SEE BELOW WARNING!)
> 
> WARNING!!! as previously explained,… you _MUST_ have the patches that I sent to avg and mav to be able to "just drop in these menu.rc files and reboot" -- if you drop anything but the HEAD menu.rc into a HEAD copy of /boot … you… will… not… boot… !!!
> 
> For a copy of what I sent to avg and mav, check out my twitter account or drop me a line.

-- 
Devin

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.