Date: Sun, 7 Oct 2012 08:53:26 -0700 From: Garrett Cooper <yanegomi@gmail.com> To: Devin Teske <dteske@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: New Boot Loader Menu Message-ID: <CAGH67wT4fDo9Du9e9vyzowrEMtn=g6SPROVLRYc-Xogvvk2OkQ@mail.gmail.com> In-Reply-To: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Oct 6, 2012 at 4:48 PM, Devin Teske <devin.teske@fisglobal.com> wro= te: > Hello, > > I've been working on a new boot loader menu system. > > This is what is in HEAD, CURRENT, and RELENG_9 at the moment: > > http://twitpic.com/b1pkll/full > in color: http://twitpic.com/b1pkz1/full > > I'd like to propose the following replacement to the above: > > http://twitpic.com/b1pll5/full > in color: http://twitpic.com/b1plxi/full > > The boot options have been whisked away into a sub-menu (see below): > > http://twitpic.com/b1pm51/full > in color: http://twitpic.com/b1pme8/full > > What does everybody think? A few things: 1. It makes things cleaner for humans who want to get essential tasks done, 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). 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 :)? 3. There isn't really a limit on how much the submenus could or should grow; oh, and Forth can be a black art of sorts. 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. > NOTE: This change is not trivial. It took me nearly a month of hacking to= produce this _and_ almost 1,000 changed lines of code are required. Featur= es 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 t= hese features, but we have a choice of keeping the menu as-is without any c= hanges _or_ we can choose to use the new features (as exhibited in this pro= posal -- where the boot options are sidled-off into a submenu). 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. 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*. > P.S. The hope is to one day utilize _all_ of the features I'm adding to o= ne day have something like this (a functioning mock-up, but unfinished curr= ently): http://twitter.com/devinteske/status/254419042104909824 Hmmm... Thanks! -Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGH67wT4fDo9Du9e9vyzowrEMtn=g6SPROVLRYc-Xogvvk2OkQ>