From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 15:53:27 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E8541065670; Sun, 7 Oct 2012 15:53:27 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3B8338FC12; Sun, 7 Oct 2012 15:53:27 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so4139547oag.13 for ; Sun, 07 Oct 2012 08:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=HSvd1kqTP0ylivSgET5ZtXOPixtebq45/lORsGdzUug=; b=nUBNfK7I43OIeuFy4n7OrA7ihhyUXvX04wtMf97ZQcSY/XzSt23GaIkUrsNF2O9fcr o3Sfa7Mc79JKlxbVxkRJtA7eDbutBtbO+OTq0rJtexd2AHCwrjpCeJ5sFV5OGxgI4frI 3Ydw/ImNvNtMlHBuygdoPdHkhyv385GboeT/YyLqk7QVpXfXR07pW/47H9tUNvkKJQUt kgFd+ubGMQPFdkebIisfvxSWlAqs9DnDMBSV/LRPHFspeF28APDEP1D5RPVDpFScR1fg XsjnnxSSDKyl4+BlOcVaehvIsS31wdQHlsWcK249Z1Pz9sMVkDl3olwIb7bbdhqPNe9g Bwng== MIME-Version: 1.0 Received: by 10.60.30.136 with SMTP id s8mr11028017oeh.81.1349625206655; Sun, 07 Oct 2012 08:53:26 -0700 (PDT) Received: by 10.76.167.202 with HTTP; Sun, 7 Oct 2012 08:53:26 -0700 (PDT) In-Reply-To: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> Date: Sun, 7 Oct 2012 08:53:26 -0700 Message-ID: From: Garrett Cooper To: Devin Teske Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org Subject: Re: New Boot Loader Menu X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 15:53:27 -0000 On Sat, Oct 6, 2012 at 4:48 PM, Devin Teske 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