Date: Sun, 7 Oct 2012 11:33:12 -0700 From: Devin Teske <devin.teske@fisglobal.com> To: Garrett Cooper <yanegomi@gmail.com> Cc: Devin Teske <dteske@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: New Boot Loader Menu Message-ID: <40D3D045-7B7F-41C4-BE8C-C44E60BA84B2@fisglobal.com> In-Reply-To: <CAGH67wT4fDo9Du9e9vyzowrEMtn=g6SPROVLRYc-Xogvvk2OkQ@mail.gmail.com> References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <CAGH67wT4fDo9Du9e9vyzowrEMtn=g6SPROVLRYc-Xogvvk2OkQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 7, 2012, at 8:53 AM, Garrett Cooper wrote: > On Sat, Oct 6, 2012 at 4:48 PM, Devin Teske <devin.teske@fisglobal.com> w= rote: >> Hello, >>=20 >> I've been working on a new boot loader menu system. >>=20 >> This is what is in HEAD, CURRENT, and RELENG_9 at the moment: >>=20 >> http://twitpic.com/b1pkll/full >> in color: http://twitpic.com/b1pkz1/full >>=20 >> I'd like to propose the following replacement to the above: >>=20 >> http://twitpic.com/b1pll5/full >> in color: http://twitpic.com/b1plxi/full >>=20 >> The boot options have been whisked away into a sub-menu (see below): >>=20 >> http://twitpic.com/b1pm51/full >> in color: http://twitpic.com/b1pme8/full >>=20 >> What does everybody think? >=20 > A few things: > 1. It makes things cleaner for humans who want to get essential tasks > done, My original thought was: *this* is going to finally allow us to accommodate= the additional menu items that iX is planning (like BE integration). But (similar to the "make things cleaner" thought), my second thought was: *this* is going to finally get those field engineers to stop asking me "sho= uld I change anything on this menu" and if it doesn't, at least now I can s= ay "don't change anything in the options *menu*" (more clear separation of = "action items" versus [possibly] vestigial protuberances that should be ign= ored by the casual observer). I think we often forget that *everybody* that boots FreeBSD (be it the "fie= ld engineer", the "programmer", the "sys admin", or even -- and this is the= kicker -- the "remote controlled non-techie sitting on the phone with a te= chie trying to help solve a problem only because he's the only warm body in= the remote site which unfortunately has lost access" person) see this menu= . It's that mindset that makes me think that "less is more" and "clear sepa= ration so we can say ``don't touch that menu'' versus ``don't touch those 4= items''" is a win, not a loss. > but it also makes it a little bit harder for automation to "dive > down" into the next level and test stuff (unless OFC the beastie menu > was completely bypassed, which might be something that I need to do in > the future for automation as the bootloader prompt never really > changes). Well, if you were automating things, I would hope that you were setting thi= ngs in loader.conf(5), not relying on a written procedure. That is to say that, setting boot_verbose=3D"YES" in loader.conf(5) is a be= tter way of automating verbose-booting opposed to requiring someone to hit = "v" before booting each time. The effect of these settings (in loader.conf(= 5)) is not proposed to change -- they would work the same regardless of whe= ther the menu item is in the main menu or a submenu. Last, but not least, the written procedure would only change slightly. If y= ou want to boot into single-user mode, for example, currently you'd press "= s" then "ENTER". With the menu item moved to a submenu, you'd instead press= "o" then "s" then ENTER. What's worth noting is that "ENTER" will work on = any menu or submenu to boot. There would be no need to go back to the main = menu to boot (you can boot directly from the options submenu). > 2. This makes it harder for people rolling custom patches on the > bootloader to continue using them, but I suppose porting is "all in a > day's work", right :)? How so? Isn't that true _anytime_ patches are made? Actually, I've made very little changes to everything that is currently the= re with the exception of the massive/new "menusets.4th" What's worth noting about these enhancements are they are only additive in = nature. No functionality was removed, only added _and_ existing menu.rc set= ups will continue to work. When I give my live demo this coming Thursday at BAFUG, I'll be demonstrati= ng how the existing menu.rc in HEAD can be used with zero changes to the Fo= rth code; then demonstrate 3 _new_ menu.rc files which successively demonst= rate more features with more complex setups (but again with zero changes to= the Forth code). This shows retention of backward compatibility. I'll remind the community that the major goal of these enhancements (starti= ng with the enhancements I made 16+ months ago) were to alleviate the need = to continually be changing the Forth code. That instead of always implement= ing new Forth code, that changes in functionality (even additions of new me= nus) could be done by merely setting a collection of precisely-named enviro= nment variables (which can be done in the POSIX C layer, a simple *.rc file= , or even loader.conf(5) -- but no Forth modifications). These enhancements= follow the same line of thinking and make it even more likely that (if peo= ple accept these patches into their own custom distributions down-stream fr= om FreeBSD) patches are less necessary. > 3. There isn't really a limit on how much the submenus could or should > grow; Right now, I've programmed in an upper limit of 65535 possible submenus. Ea= ch submenu can have up to 9 maximum (tho we like to keep it at 8 for multip= le reasons) menu items. Each of those menu items can be a static-type, togg= le type, cycle type, or submenu type (meaning there is a common infrastruct= ure for these types; you can do anything you want for a menu item by creati= ng any call-back you desire and said call-back can be provided either by th= e Forth layer or the POSIX C layer). > oh, and Forth can be a black art of sorts. >=20 Yes, it can. That's why I've been working hard on getting call-back systems= functioning properly so folks like avg and mav can have fully dynamic menu= s driven by C-based call-backs (with zero Forth work). > Even though I can see its merits, I do see where des@ is coming from. > It's good to see some discussion before commit, but I think it > deserves a bit more thought and some rough sketches to come up with a > solid (or at least squishy) plan on how to proceed. >=20 agreed. >> NOTE: This change is not trivial. It took me nearly a month of hacking t= o produce this _and_ almost 1,000 changed lines of code are required. Featu= res such as submenus, dynamic menus and menu items, and more were added and= I'm at a point where I can commit this back to the tree. I'm sure we want = these features, but we have a choice of keeping the menu as-is without any = changes _or_ we can choose to use the new features (as exhibited in this pr= oposal -- where the boot options are sidled-off into a submenu). >=20 > That might be harder to work with. sysinstall was usable to a point, > but then it got unusable after a period of time because of the way > libdialog was changed, and then unfortunately it was abandoned after a > while. We'd rather avoid those usability "mistakes" in the future if > at all possible. >=20 I think you misunderstand. When I say that we have a choice to not make any= changes, what I meant was that after all the enhancements are in, there's = nothing forcing us to use them. That everything is backward compatible and = that the existing menu.rc does not have to change (tho a quick note about t= hat below). Tho the infrastructure is not losing any functionality, we ought to at leas= t use the new "dynamic menuitem" constructors to fix a bug that currently p= lagues HEAD -- the fact that setting boot_verbose=3D"YES" (as just one exam= ple) in loader.conf(5) will not be reflected in the main boot menu. At the = very least, we should use the dynamic initialization feature to fix that bu= g even if we don't end up pushing the options to a submenu. > As always, as usable, simple, and maintainable as possible is what we > should shoot for in the project. if it makes sense, things maybe > should be split up into separate menus with a common boilerplate > *shrugs*. >=20 Usable, simple, maintainable _and_ easily extendable was what I was shootin= g for. I understand a lot of people don't hack on the Forth code -- I've be= en having fun and excitement with it for over 8 years, but alas I understan= d a lot of people aren't excited-by or have-fun with it. So I've tried to p= ush all the functionality into the other layers where people are adeptly sk= illed and there is no shortage of programmers (namely the C and config spac= es). Oh, and with respect to the "boilerplate" comment: that's actually possible= . Menus (or submenus) can be wholly static, wholly dynamic, or any percenta= ge thereof. In one demo I'll be giving this Thursday (BAFUG), the root-devi= ce selection menu has one static menu item and many dynamically-generated m= enu items. So this is something that is definitely do-able if we want. >> P.S. The hope is to one day utilize _all_ of the features I'm adding to = one day have something like this (a functioning mock-up, but unfinished cur= rently): http://twitter.com/devinteske/status/254419042104909824 >=20 > Hmmm=85 >=20 You'll have to talk to mav and jpaetzel about their plans for the "BE subme= nu" -- I hope to pick some brains this Thursday at BAFUG to see what it mig= ht look like, how it might function, etc. but right now I don't know how th= ey are going to use my new menuing infrastructure. What I posted was just a= mock-up of what I think might be useful (filtering on type and having a me= nu for setting vfs.root.mountfrom based on lsdev/lszfs output). --=20 Cheers, Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40D3D045-7B7F-41C4-BE8C-C44E60BA84B2>