From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 20:27:12 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 39F2C106564A; Sun, 7 Oct 2012 20:27:12 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id B77B68FC16; Sun, 7 Oct 2012 20:27:11 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa06.fnfis.com (8.14.4/8.14.4) with ESMTP id q97KRAP3026699 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 7 Oct 2012 15:27:10 -0500 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.17) with Microsoft SMTP Server (TLS) id 14.2.309.2; Sun, 7 Oct 2012 15:27:10 -0500 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Devin Teske In-Reply-To: <5071D6B5.1010609@FreeBSD.org> Date: Sun, 7 Oct 2012 13:27:08 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <5071D6B5.1010609@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1283) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-10-07_05:2012-10-06, 2012-10-07, 1970-01-01 signatures=0 Cc: Devin Teske , freebsd-arch@freebsd.org Subject: Re: New Boot Loader Menu X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Devin Teske 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 20:27:12 -0000 On Oct 7, 2012, at 12:23 PM, Doug Barton wrote: > On 10/06/2012 16:48, Devin Teske wrote: >=20 >> 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. >=20 > It's generally a good idea to ask for feedback before spending this > amount of time on something. I will agree that _generally_ it's a good idea, but in my case feedback mak= es no difference with respect to how much effort I put into something like = this. The reason being that these features, if not taken into FreeBSD, will simpl= y live on happily in DruidBSD. The boot loader menu that is currently used in FreeBSD HEAD, CURRENT, and R= ELENG_9 in-fact was used in DruidBSD for nearly 7 years before it was impor= ted to FreeBSD. > Coming to the community and saying, "I > spent so much time on this, you have to accept it" doesn't fly. >=20 I reject your proposed hypothesis that this was my intent (the proper inten= t is described below). > "But that's not why I mentioned how many hours I spent." > "So why mention it at all?" :) >=20 My precise intent for mentioning this was for the other Forth and/or boot-m= enu folks (not the casual person). I didn't want the other Forth hackers to get excited and perhaps form the m= arkedly false impressions that either: a. the current code allows for submenus b. that submenus were easy to add c. that shoving the boot options into a submenu is something that can be do= ne with a "1 line commit" Rather, I sought to set the stage that if the proposed "end result" is desi= rable, it would give me impetus to continue working in that direction (whic= h is a tiny fork in the end of a long road of committing ~1000 lines of req= uisite enhancements). By providing the information I did at the end, I was not stating "I worked = hard on this, you must accept it," but rather I was stating "here's somethi= ng nice, if you want it I'm prepared to make it happen and this is what you= can expect to be committed as-described by said effort." I did not perceive that anybody would construe my statement-of-effort as an= ything other than being totally up-front about what went into the final pro= posed-product versus trying to be sneaky and pull a "bait and switch" (some= thing I definitely would have perceived if somebody _didn't_ itemize the ef= fort that went into something that *looked* simple or *sounded* easy). >> Features 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 proposal -- where the boot >> options are sidled-off into a submenu). >=20 > Others have already brought up their favorite items to keep at the top > level, I think it would be much simpler to leave everything that is at > the top level now, and make submenus option number 8. What name would you give this "all submenus" menu item? Because, as previou= sly discussed, if the menu stays as-is, we can really only have one more it= em and so said-new-item would have to be an "all submenus" option. Somehow,= I don't think jpaetzel, avg, and mav are going to like this as a solution = for their proposed-new "BE menu" (having "8. Submenus" -> "2. BE Submenu" -= > "Select a BE" just seems too deep-a-traversal). > Bonus points if > you can make it easy to add a submenu via loader.conf. >=20 Done. There's zero difference in configuring menus in a "menu.rc" file than= in "loader.conf" file. Menus (and submenus alike) are configured via appropriately named environme= nt variables. How these environment variables get set is entirely up to the= clients of my framework. You can set them via menu.rc, loader.conf, in the= C layer (e.g., sys/boot/ficl/loader.c), or the Forth layer. It makes no di= fference. However, I implore everybody to stay away from the Forth layer be= cause adding massive amounts of static text to that layer can *quickly* cau= se dictionary overflow which leads to immediate and fatal BTX halt. Setting= the environment variables in menu.rc, loader.conf, or the C layer doesn't = suffer from the limitations of the FICL dictionary size (and bumping the di= ctionary size is not always the right solution). > Regarding the UI on your submenu example; never, ever, ever use > Backspace to mean anything other than "delete the character behind the > cursor." Seriously? Who made _that_ rule? and moreover, _WHY_? My reasoning=85 you want to be able to account for non-responsive systems i= n which case the user jams on a given key because they don't get a screen-u= pdate right-away. In this case, what's the harm in jamming on Backspace? Ev= en if they somehow drop to an interactive prompt and are still jamming Back= space, what's the harm? I don't understand this out-of-the-blue axiom. Can you or someone explain its origins and or enlighten me to the edge-case= that led to its creation? I'l in-turn become one a staunch follower, I jus= t want to know the pathos behind it. > Unfortunately you cannot use 'B' or Escape here either since > they have meaning in the previous menu. Right-o > 'Left Arrow' is likely the best > choice, although Home or even 'Page Up' would be better than Backspace. >=20 Hmmm, I find myself wishing that there could be multiple keycodes associate= d with a given menuitem, but at this time there's really only one keycode t= hat can be set (without further enhancement). I'll try playing around, but I'm afraid that backspace just felt so "right"= that my hands won't want to do anything else. I can tell you from playing around with submenus for quite awhile, that it'= s sometimes annoying (until you get the repetition down) having to hunt for= the key to "take me back" (and backspace just seemed "right" as the key to= "take me back" no matter where I am). It also seemed to play well because = I was logically perceiving a traversal to the right into the submenu, and (= perhaps this is strictly because I am a native English speaker that types l= eft-to-right), backspace was the logical correct thing to take me back "to = the left" just as it does when typing. --=20 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.