From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 00:15: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 5122F1065670 for ; Sun, 7 Oct 2012 00:15:27 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by mx1.freebsd.org (Postfix) with ESMTP id B1B118FC0A for ; Sun, 7 Oct 2012 00:15:26 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUHDJmNYsHBfNyX+ty6htzqfUemlRl+0G@postini.com; Sat, 06 Oct 2012 17:15:26 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 6 Oct 2012 17:14:24 -0700 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q970ENh00745 for ; Sat, 6 Oct 2012 17:14:23 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 9878F58094 for ; Sat, 6 Oct 2012 17:14:23 -0700 (PDT) To: X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Sat, 6 Oct 2012 17:14:23 -0700 From: Simon Gerraty Message-ID: <20121007001423.9878F58094@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain Subject: bsd.own.mk - just let WITHOUT_* take precedence 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 00:15:27 -0000 After being bitten by: make: "/b/sjg/work/fbsd-head/src/share/mk/bsd.own.mk" line 490: WITH_CTF and WITHOUT_CTF can't both be set. I took a look at bsd.own.mk I'm not sure what's so evil about setting both WITH_ and WITHOUT_ especially when bits of buildworld, buildkernel etc, set WITHOUT_ (which triggers the problem for me). All that seems necessary is a clear rule - "WITHOUT_ wins". Thus the patch below solve my problem. Index: share/mk/bsd.own.mk =================================================================== --- share/mk/bsd.own.mk (revision 241871) +++ share/mk/bsd.own.mk (working copy) @@ -468,9 +468,6 @@ __DEFAULT_NO_OPTIONS+=FDT # MK_* options which default to "yes". # .for var in ${__DEFAULT_YES_OPTIONS} -.if defined(WITH_${var}) && defined(WITHOUT_${var}) -.error WITH_${var} and WITHOUT_${var} can't both be set. -.endif .if defined(MK_${var}) .error MK_${var} can't be set by a user. .endif @@ -486,13 +483,10 @@ MK_${var}:= yes # MK_* options which default to "no". # .for var in ${__DEFAULT_NO_OPTIONS} -.if defined(WITH_${var}) && defined(WITHOUT_${var}) -.error WITH_${var} and WITHOUT_${var} can't both be set. -.endif .if defined(MK_${var}) .error MK_${var} can't be set by a user. .endif -.if defined(WITH_${var}) +.if defined(WITH_${var}) && !defined(WITHOUT_${var}) MK_${var}:= yes .else MK_${var}:= no From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 11:10:08 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 DA1DA106566C; Sun, 7 Oct 2012 11:10:08 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 941B48FC14; Sun, 7 Oct 2012 11:10:08 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 419236BED; Sun, 7 Oct 2012 13:10:07 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id BCC9983F9; Sun, 7 Oct 2012 13:10:06 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Devin Teske References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> Date: Sun, 07 Oct 2012 13:10:06 +0200 In-Reply-To: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> (Devin Teske's message of "Sat, 6 Oct 2012 16:48:50 -0700") Message-ID: <86k3v21qsx.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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 11:10:09 -0000 Devin Teske writes: > What does everybody think? I think it's a terrible idea. What problem are you trying to solve, exactly? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no 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 From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 16:34:46 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 7D464106566B; Sun, 7 Oct 2012 16:34:46 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 2B5FD8FC14; Sun, 7 Oct 2012 16:34:45 +0000 (UTC) Received: from outgoing.leidinger.net (p5DD45DBD.dip.t-dialin.net [93.212.93.189]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 24737844006; Sun, 7 Oct 2012 18:34:38 +0200 (CEST) Received: from unknown (IO.Leidinger.net [192.168.1.12]) by outgoing.leidinger.net (Postfix) with ESMTPS id 882621F16; Sun, 7 Oct 2012 18:34:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1349627675; bh=AZt5mF8iEhBItv9pjBXBc+TnLpDjJLtW29RyrRwNGW0=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=3LkdX9VlV8LUlodNG+jfehPAkw0rl5CkT9yvj/I+ou2Oy40GMQmjOML7aGPwtd1IF +RLRZYA3mAP7KljgEwaVDpFwX+vXyOi1kgCIfaMtbd5x7RnyRP3N32Z9q9o2ImeHKg sW+57QczyglJG5kEeT0ITFic+qixiLyFjulN8wqrzbyKBV1Q8RBSUSMgorv5OXd55I wg98045u4d86MemaYfcQ29ErzH1wZgJ/kvpUhZVpCijIE5QMBYpmvuxsre5Pr13bXL oEI6lgL+HMCgIzEu34/jyaZT6UbnJ8riS3Bgv0YEhGwnkSVqkASo1Pk5HmZrWqtz8w V5QHYpOvThc4w== Date: Sun, 7 Oct 2012 18:34:33 +0200 From: Alexander Leidinger To: Devin Teske Message-ID: <20121007183433.000026a6@unknown> In-Reply-To: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> X-Mailer: Claws Mail 3.8.0cvs30 (GTK+ 2.24.10; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 24737844006.AF891 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.091, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL 0.02, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1350232481.96761@zbf/RDk711R05HAi4AeDqw X-EBL-Spam-Status: No Cc: devin.teske@fisglobal.com, 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 16:34:46 -0000 On Sat, 6 Oct 2012 16:48:50 -0700 Devin Teske wrote: > 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? IMO single user mode should be in the first level. I never had to use the other options, but I often used single-user mode. Another reson is that we tell to install the world in single-user mode. While I've always installed the world in multi-user mode, we should make it easy/fast to do it the recommended way. I see a lot of value for submenus to chose another boot device / partition, specially with ZFS boot environments. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 17:04:42 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 4C0E5106566C; Sun, 7 Oct 2012 17:04:42 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6A65D8FC1E; Sun, 7 Oct 2012 17:04:40 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA15935; Sun, 07 Oct 2012 20:04:39 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TKuHP-0008NS-1i; Sun, 07 Oct 2012 20:04:39 +0300 Message-ID: <5071B625.6090906@FreeBSD.org> Date: Sun, 07 Oct 2012 20:04:37 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120913 Thunderbird/15.0.1 MIME-Version: 1.0 To: Devin Teske References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> In-Reply-To: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 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 17:04:42 -0000 on 07/10/2012 02:48 Devin Teske said the following: > 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? Can't say for everybody :-) I think that the infrastructure is great. How you chose to use it in your demo might turn off some people though :-) I mean hiding of the traditional options into the sub-menu. Let's use sub-menus for the really useful stuff. Like detailing safe boot options (e.g. under Troubleshooting sub-menu; ACPI can got there too) or offering a GUI way to chose a boot+root filesystem (esp. for ZFS). Please don't mind the people who react to screenshots rather than to your work (and thus, perhaps, can't see the wood behind the trees). Whatever you do, verbose boot and single-user mode must stay on the first page. At least until the next round of evolution. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 17:24:55 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 F06061065670 for ; Sun, 7 Oct 2012 17:24:54 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id BBC878FC17 for ; Sun, 7 Oct 2012 17:24:54 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so3672720pad.13 for ; Sun, 07 Oct 2012 10:24:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VtVWAYQPUkYFOz1W8388jCDLjj9BDhztEOkzXLHI7Pk=; b=chTAhAnwPdv81uX4iT6rnis9EyFtD7BgFo2JpxKDBhgPgE/Jblo+uAPRvliLWLQbQ+ hOZsq+YeUmDUfVAPdWJj5LOrNb4tRNfdzjTajunfS3YFAknZt0b6MFOUgM6cfKrmJMb1 aRFI9oukd13Rhhjes8wALni38rV4Ooww4oQKo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=VtVWAYQPUkYFOz1W8388jCDLjj9BDhztEOkzXLHI7Pk=; b=Txl6wjAMPKhrQC5IFph+PHGNrLvighJXLn5ALd4AsDV3rfC9f82SbhjyU3KgO8QAJj YkCW/xaFmOjVrJ7Wy/SirblqbzGOaoa3WJqaoOf5aMTCkc5hiOh1wJtDkn71c4C6UavB lIDNn/0E+4s6nQDntWNFULcLvhPFbVvXEp8GAoBYRZqhQewHmCS9TSg91W54CV2L3Gx3 +fiJPg38+9uIvb6QzLSAs+h3Mx/Eoop4ta2tOql/rOWvuawUjMBYhUM92SebaFrNrFCv S9PYuIKB+i46VU6c1U6ad0F9Dqd7pxVy6El52O/6q0A9yLfaHJ2/QDox7z9N7RZnTQ3L 3A+Q== Received: by 10.66.81.202 with SMTP id c10mr36933110pay.31.1349630694234; Sun, 07 Oct 2012 10:24:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.161.163 with HTTP; Sun, 7 Oct 2012 10:24:23 -0700 (PDT) In-Reply-To: <5071B625.6090906@FreeBSD.org> References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <5071B625.6090906@FreeBSD.org> From: Eitan Adler Date: Sun, 7 Oct 2012 13:24:23 -0400 Message-ID: To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQluabQEGP9ea2kSpkyH4E45OmupbhDxdehP4BapyxW9GUk1clZ+bIOnQFxakhvAdVrwfIh8 Cc: Devin Teske , 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 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 17:24:55 -0000 On 7 October 2012 13:04, Andriy Gapon wrote: > on 07/10/2012 02:48 Devin Teske said the following: >> 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? > > > Can't say for everybody :-) > I think that the infrastructure is great. How you chose to use it in your demo > might turn off some people though :-) I mean hiding of the traditional options > into the sub-menu. > > Let's use sub-menus for the really useful stuff. Like detailing safe boot > options (e.g. under Troubleshooting sub-menu; ACPI can got there too) or > offering a GUI way to chose a boot+root filesystem (esp. for ZFS). > > Please don't mind the people who react to screenshots rather than to your work > (and thus, perhaps, can't see the wood behind the trees). > > Whatever you do, verbose boot and single-user mode must stay on the first page. > At least until the next round of evolution. I completely agree with avg@ here. -- Eitan Adler From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 17:51:42 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 BD6B11065787; Sun, 7 Oct 2012 17:51:42 +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 7F3678FC1B; Sun, 7 Oct 2012 17:51:42 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa01.fnfis.com (8.14.4/8.14.4) with ESMTP id q97Hpdsb011521 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 7 Oct 2012 12:51:39 -0500 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.15) with Microsoft SMTP Server (TLS) id 14.2.309.2; Sun, 7 Oct 2012 12:51:38 -0500 MIME-Version: 1.0 (Apple Message framework v1283) From: Devin Teske In-Reply-To: <86k3v21qsx.fsf@ds4.des.no> Date: Sun, 7 Oct 2012 10:51:37 -0700 Message-ID: <3EB58454-7820-43C4-911E-7DEF2D02C880@fisglobal.com> References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <86k3v21qsx.fsf@ds4.des.no> To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= 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 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 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 17:51:42 -0000 On Oct 7, 2012, at 4:10 AM, Dag-Erling Sm=F8rgrav wrote: > Devin Teske writes: >> What does everybody think? >=20 > I think it's a terrible idea. >=20 > What problem are you trying to solve, exactly? >=20 Many in-fact: 1. Growth issue. There's a ceiling to how many menu items a menu can have. + iX affiliates have come to me requesting accommodations for a submenu. + Adding said proposed submenu to the main menu (seen here: http://twitpic.= com/b1pkll/full) would leave practically no room for any further additions. 2. Exploring that last statement ("no room for any further additions")=85 + Practical and technical limitations prevent us from having more than 9 me= nu items. Coding around this is non-trivial (it goes all the way down to th= e raw ASCII codes that are generated when an associative keycode is pressed= ). + Due to the aforementioned technical/practical limitations, there's little= point in exploring the thought of: "what if we just got rid of Beastie to = make more room for the menu". Yielding more screen real estate for the menu= would not lift the technical limitations still limiting each menu from hav= ing at-maximum 9 items. 3. A bug is actually present in the current menu system. + Setting boot_verbose=3D"YES" in loader.conf(5) and rebooting, the current= menu system will not reflect this and the menu comes up saying "Verbose...= .. No". Although it is not and was not necessary to move the options to a s= ubmenu to fix this (in truth, the "dynamic menuitems" enhancement will fix = that and does not require the use of submenus), it was easier for *me* to t= est the dynamic menuitem initialization (aka constructor call-back) feature= enhancement if the option was in a submenu (since *re*-visiting a submenu = is akin to rebooting had I not moved the items off the main menu). + gnn was the one that reported this bug to me in early September. That was= a busy month because shortly thereafter, avg came at me with the request t= o accommodate submenus. I immediately recognized that these two requests (b= ugfix + enhancement) could be rolled into the same patchset (related featur= es). --=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. From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 18:33:22 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 090A3106566C; Sun, 7 Oct 2012 18:33:22 +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 C0F7A8FC08; Sun, 7 Oct 2012 18:33:21 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa07.fnfis.com (8.14.4/8.14.4) with ESMTP id q97IXFXh003800 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 7 Oct 2012 13:33:20 -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 13:33:15 -0500 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Devin Teske In-Reply-To: Date: Sun, 7 Oct 2012 11:33:12 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <40D3D045-7B7F-41C4-BE8C-C44E60BA84B2@fisglobal.com> References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> To: Garrett Cooper 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 18:33:22 -0000 On Oct 7, 2012, at 8:53 AM, Garrett Cooper wrote: > On Sat, Oct 6, 2012 at 4:48 PM, Devin Teske 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. From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 18:44:30 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 9370C10656C3; Sun, 7 Oct 2012 18:44:30 +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 5A4C58FC1A; Sun, 7 Oct 2012 18:44:30 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa01.fnfis.com (8.14.4/8.14.4) with ESMTP id q97IiRIf007965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 7 Oct 2012 13:44:27 -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 13:44:26 -0500 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Devin Teske In-Reply-To: <20121007183433.000026a6@unknown> Date: Sun, 7 Oct 2012 11:44:25 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <20121007183433.000026a6@unknown> To: Alexander Leidinger 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 18:44:30 -0000 On Oct 7, 2012, at 9:34 AM, Alexander Leidinger wrote: > On Sat, 6 Oct 2012 16:48:50 -0700 Devin Teske > wrote: >=20 >> 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 >>=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 >>=20 >> What does everybody think? >=20 > IMO single user mode should be in the first level. I never had to use > the other options, but I often used single-user mode. Another reson is > that we tell to install the world in single-user mode. While I've > always installed the world in multi-user mode, we should make it > easy/fast to do it the recommended way. >=20 The documentation on how to get into single-user mode would need to be chan= ged from: Press 's' and 'ENTER' to instead: Press 'o' then 's' then 'ENTER' NOTE: The menu/submenu infrastructure hooks "ENTER" in at the lowest level = possible, so at any time=85 ENTER =3D=3D boot (regardless of whether a menu= or submenu has a "Boot" menu item and/or regardless of whether any menuite= m has hooked in the ASCII keycode for ENTER; ENTER =3D=3D boot no matter wh= ere you are in the menu at any time). Thus, it is not required to "go back"= to the main menu to boot -- you can jump to the options submenu, make your= changes, and then boot with those options by pressing ENTER. Please note that 16+ months ago we had to update the documentation for my l= ast enhancement to the loader menu. It used to be: Press 's' and changed to: Press 's' then 'ENTER' because we went from a stateless menu system to a stateful menu system. The= driving force behind that was indeed the fact that with the old stateless = menu, you could not ever boot with combinations-of-options (but rather you = could only boot with options that were presented -- unless of course you dr= opped to the interactive prompt and did the dirty work yourself). > I see a lot of value for submenus to chose another boot device / > partition, specially with ZFS boot environments. >=20 Agreed. But it's when we add that submenu to the main menu that things now get so c= rowded that a redesign would be absolutely necessary if we were to add any = other option. --=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. From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 18:52:02 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 0B1441065672; Sun, 7 Oct 2012 18:52:02 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id BEECF8FC16; Sun, 7 Oct 2012 18:52:01 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 828F66D04; Sun, 7 Oct 2012 20:51:55 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 17473843F; Sun, 7 Oct 2012 20:51:54 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Devin Teske References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <86k3v21qsx.fsf@ds4.des.no> <3EB58454-7820-43C4-911E-7DEF2D02C880@fisglobal.com> Date: Sun, 07 Oct 2012 20:51:54 +0200 In-Reply-To: <3EB58454-7820-43C4-911E-7DEF2D02C880@fisglobal.com> (Devin Teske's message of "Sun, 7 Oct 2012 10:51:37 -0700") Message-ID: <86fw5q15f9.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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 18:52:02 -0000 Devin Teske writes: > Dag-Erling Sm=C3=B8rgrav writes: > > What problem are you trying to solve, exactly? > Many in-fact: > [list of things that bear no relation whatsoever to what was actually > in the email I replied to] Then maybe you should have focused on that in your original email. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 18:52: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 E3DB91065670; Sun, 7 Oct 2012 18:52:26 +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 AA1CC8FC12; Sun, 7 Oct 2012 18:52:26 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa02.fnfis.com (8.14.4/8.14.4) with ESMTP id q97IqPHi030466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 7 Oct 2012 13:52:25 -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 13:52:24 -0500 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="iso-8859-1" From: Devin Teske In-Reply-To: <5071B625.6090906@FreeBSD.org> Date: Sun, 7 Oct 2012 11:52:23 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <8FC2C78A-5F4E-4F87-AC63-D1B554E13505@fisglobal.com> References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <5071B625.6090906@FreeBSD.org> To: Andriy Gapon 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 18:52:27 -0000 On Oct 7, 2012, at 10:04 AM, Andriy Gapon wrote: > on 07/10/2012 02:48 Devin Teske said the following: >> 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 >>=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 >>=20 >> What does everybody think? >=20 >=20 > Can't say for everybody :-) > I think that the infrastructure is great. How you chose to use it in you= r demo > might turn off some people though :-) I mean hiding of the traditional o= ptions > into the sub-menu. >=20 That wasn't a demo, that's my honest-to-goodness proposed replacement for H= EAD. ^_^ > Let's use sub-menus for the really useful stuff. Like detailing safe boot > options (e.g. under Troubleshooting sub-menu; ACPI can got there too) or > offering a GUI way to chose a boot+root filesystem (esp. for ZFS). >=20 I'm here to provide the infrastructure. I'll admit that: + I'm not the one to decide how my infrastructure is best used. + we desperately need to discuss before making any changes. I just knew how to provide the necessary infrastructure in a way that: + didn't break backward compatibility for the old/current menu + could accommodate more functionality than was available + could accommodate the features iX approached me about* * such as BE menu (which I've not yet talked about to any great length YET,= so I am myself very short on details as I think we're still in the design = phase) > Please don't mind the people who react to screenshots rather than to your= work > (and thus, perhaps, can't see the wood behind the trees). >=20 True. Tho it may be nice to give those that don't know Forth a chance to pa= rticipate. > Whatever you do, verbose boot and single-user mode must stay on the first= page. > At least until the next round of evolution. >=20 I'm not committing to making any changes to the visible functionality at th= is time (beyond fixing the bug that gnn brought to my attention -- with res= pect to initial-state of things like boot_verbose from loader.conf(5) not b= eing adhered to). What's there will remain as-is until we come to an agreement on what to do. However, I will move forward with committing-back _all_ functionality enhan= cements (which will remain largely unused at this point until either iX com= es in with the BE menu code or we decide to shunt some-or-all of the ancill= ary boot options off to a submenu). --=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. From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 19:03:56 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 EC223106566C; Sun, 7 Oct 2012 19:03:56 +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 B041B8FC08; Sun, 7 Oct 2012 19:03:56 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa06.fnfis.com (8.14.4/8.14.4) with ESMTP id q97J3sKu023922 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 7 Oct 2012 14:03:54 -0500 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.16) with Microsoft SMTP Server (TLS) id 14.2.309.2; Sun, 7 Oct 2012 14:03:53 -0500 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Devin Teske In-Reply-To: <86fw5q15f9.fsf@ds4.des.no> Date: Sun, 7 Oct 2012 12:03:51 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <86k3v21qsx.fsf@ds4.des.no> <3EB58454-7820-43C4-911E-7DEF2D02C880@fisglobal.com> <86fw5q15f9.fsf@ds4.des.no> To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= 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 19:03:57 -0000 On Oct 7, 2012, at 11:51 AM, Dag-Erling Sm=F8rgrav wrote: > Devin Teske writes: >> Dag-Erling Sm=F8rgrav writes: >>> What problem are you trying to solve, exactly? >> Many in-fact: >> [list of things that bear no relation whatsoever to what was actually >> in the email I replied to] >=20 I disagree with your slight that those "things =85 bear no relation whatsoe= ver to what was actually in the e-mail [you] replied to". It only *seem* as those are unrelated. I assure you, they are _very_ relate= d (and it's very much my mistake for not making it clear in my initial e-ma= il). I must apologize for this lack of clarity (I try to rectify it below). > Then maybe you should have focused on that in your original email. >=20 Yes, perhaps. Perhaps it would have been better to explain: Hey=85 + iX and I are working on enhancing the boot loader menu to include a new s= ubmenu for selecting a Boot Environment (BE). I'm providing the menu infras= tructure, iX is providing the C code to populate that menu. + We can't add this new menu item without pigeon-holing ourselves into a po= sition where no more menuitems can be added. + This pigeon-hole has forced the hand of moving some-or-all of the boot op= tions into a submenu. + This is what it would look like. and _then_ ask: + What do you think of how it looks? --=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. From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 19:07:19 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 D9795106566B; Sun, 7 Oct 2012 19:07:19 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 98AFD8FC12; Sun, 7 Oct 2012 19:07:19 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 8FF7C6D19; Sun, 7 Oct 2012 21:07:18 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 5647F8448; Sun, 7 Oct 2012 21:07:18 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Devin Teske References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <20121007183433.000026a6@unknown> Date: Sun, 07 Oct 2012 21:07:17 +0200 In-Reply-To: (Devin Teske's message of "Sun, 7 Oct 2012 11:44:25 -0700") Message-ID: <867gr214pm.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Alexander Leidinger , 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 19:07:19 -0000 Devin Teske writes: > The documentation on how to get into single-user mode would need to be ch= anged from: > > Press 's' and 'ENTER' > > to instead: > > Press 'o' then 's' then 'ENTER' or Press ESC then type "boot -s" then press ENTER, wait for the single-user mode prompt, then type: fsck -p && mount -a && echo 'beastie_disable=3D"YES"' >>/boot/loader.conf but that's just me... DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 19:15:14 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 EC0BA1065674; Sun, 7 Oct 2012 19:15:13 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id AA9AC8FC19; Sun, 7 Oct 2012 19:15:13 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id D30BC6D33; Sun, 7 Oct 2012 21:15:12 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 9F6B7844B; Sun, 7 Oct 2012 21:15:12 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Devin Teske References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <86k3v21qsx.fsf@ds4.des.no> <3EB58454-7820-43C4-911E-7DEF2D02C880@fisglobal.com> <86fw5q15f9.fsf@ds4.des.no> Date: Sun, 07 Oct 2012 21:15:12 +0200 In-Reply-To: (Devin Teske's message of "Sun, 7 Oct 2012 12:03:51 -0700") Message-ID: <86391q14cf.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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 19:15:14 -0000 Devin Teske writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Devin Teske writes: > > > Dag-Erling Sm=C3=B8rgrav writes: > > > > What problem are you trying to solve, exactly? > > > Many in-fact: > > > [list of things that bear no relation whatsoever to what was actually > > > in the email I replied to] > I disagree with your slight that those "things =E2=80=A6 bear no relation > whatsoever to what was actually in the e-mail [you] replied to". Your original email was a proposal to hide the boot options from the boot menu (which I loathe, but that's an argument for killing it, not for making it even more horrible), with a footnote saying that the patch was well over a thousand lines. If that's not what you meant, then that's not what you should have written. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 19:23:33 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id C269C106566C; Sun, 7 Oct 2012 19:23:33 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [69.147.83.54]) by mx2.freebsd.org (Postfix) with ESMTP id 62AE414DB87; Sun, 7 Oct 2012 19:23:33 +0000 (UTC) Message-ID: <5071D6B5.1010609@FreeBSD.org> Date: Sun, 07 Oct 2012 12:23:33 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20121001 Thunderbird/15.0.1 MIME-Version: 1.0 To: Devin Teske References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> In-Reply-To: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> X-Enigmail-Version: 1.4.4 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 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 19:23:33 -0000 On 10/06/2012 16:48, Devin Teske wrote: > 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. It's generally a good idea to ask for feedback before spending this amount of time on something. Coming to the community and saying, "I spent so much time on this, you have to accept it" doesn't fly. "But that's not why I mentioned how many hours I spent." "So why mention it at all?" :) > 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). 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. Bonus points if you can make it easy to add a submenu via loader.conf. Regarding the UI on your submenu example; never, ever, ever use Backspace to mean anything other than "delete the character behind the cursor." Unfortunately you cannot use 'B' or Escape here either since they have meaning in the previous menu. 'Left Arrow' is likely the best choice, although Home or even 'Page Up' would be better than Backspace. hth, Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 19:52:15 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 26A4E106568B; Sun, 7 Oct 2012 19:52:15 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9D4E08FC0A; Sun, 7 Oct 2012 19:52:13 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so3731761pad.13 for ; Sun, 07 Oct 2012 12:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=8rU69dm+w8sxc9jCig2Wqw/rzZdh5U9LOFwO5BiMjck=; b=XClcv1IspBW6/IxZknkXPuED0nEPchNZPYZBD0TCiNG2QMNr4+HjAgkRKYrrg99Uae 6VGH9sAwhxVIBUdP1a6PyYMrmIToPxrrfmvDk/s+hAj1oVvaayjue8Z4OnOXM+ldEjoE 9pcCEKZDHXJbyakfLPGonWEUpuMCMLTJWLwPUomiSIc+5MXr4XDdn74LoOGokslAYIP4 mHWzKNL0XJVH6vIcTYeeW74O9G42ihZ37AhvjLDAWlFPlQ1ympJL+PTDENJfHRLustTL j1T+3NXTelXJV7E1ofv3LvS1Soipg0FayURzel2N85MzLjGaywPRaP5eM5KCo/n+4RlX 9wEw== Received: by 10.68.204.169 with SMTP id kz9mr47559688pbc.39.1349639532871; Sun, 07 Oct 2012 12:52:12 -0700 (PDT) Received: from fuji-wireless.local (c-24-19-191-56.hsd1.wa.comcast.net. [24.19.191.56]) by mx.google.com with ESMTPS id vf8sm9497108pbc.27.2012.10.07.12.52.09 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 07 Oct 2012 12:52:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Garrett Cooper In-Reply-To: Date: Sun, 7 Oct 2012 12:52:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <86k3v21qsx.fsf@ds4.des.no> <3EB58454-7820-43C4-911E-7DEF2D02C880@fisglobal.com> <86fw5q15f9.fsf@ds4.des.no> To: Devin Teske X-Mailer: Apple Mail (2.1283) Cc: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , 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 19:52:15 -0000 On Oct 7, 2012, at 12:03 PM, Devin Teske wrote: > On Oct 7, 2012, at 11:51 AM, Dag-Erling Sm=F8rgrav wrote: >=20 >> Devin Teske writes: >>> Dag-Erling Sm=F8rgrav writes: >>>> What problem are you trying to solve, exactly? >>> Many in-fact: >>> [list of things that bear no relation whatsoever to what was = actually >>> in the email I replied to] >>=20 >=20 > I disagree with your slight that those "things =85 bear no relation = whatsoever to what was actually in the e-mail [you] replied to". >=20 > It only *seem* as those are unrelated. I assure you, they are _very_ = related (and it's very much my mistake for not making it clear in my = initial e-mail). I must apologize for this lack of clarity (I try to = rectify it below). >=20 >> Then maybe you should have focused on that in your original email. >>=20 >=20 > Yes, perhaps. >=20 > Perhaps it would have been better to explain: >=20 > Hey=85 >=20 > + iX and I are working on enhancing the boot loader menu to include a = new submenu for selecting a Boot Environment (BE). I'm providing the = menu infrastructure, iX is providing the C code to populate that menu. Sounds like GRUB/Plymouth's model... sorta. > + We can't add this new menu item without pigeon-holing ourselves into = a position where no more menuitems can be added. Understood. ... > + What do you think of how it looks? Comments: - Graphics look ok for a text boot loader. Not too radically different = from the original rewrite, which is good. - Look at other OSes and devices for inspiration for their boot menus: = OSX and Windows might not be a good template because the menu is = obscured from the end user (or maybe not?), but there might be some = Android/Linux platforms out there that can serve as inspiration for = things which should be put in a menu. It would probably be best just to = come up with a general template based on common use cases. Once you have = an idea of the breadth of common uses in a boot menu, I would design = from there trying to determine what dimensions are that you need to make = things work (I have X items, Y levels deep to work with -- 2 is good, = and I can categorize them in this manner, which means I need this many = groups max in order to accommodate everything). - Have you considered high resolution screens/fonts; there are some = already in FreeBSD hooked into syscons, but that's available later on at = boot? I mention this because there's a lot of wasted real estate on my = 30" or 24" LCDs when I boot up FreeBSD. I'd like to see sketches or a general idea of what you have in mind = before investing too much time in a direction that doesn't bear a lot of = fruit. I'm sure others here agree. Thanks! -Garrett= From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 20:01:13 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 91492106564A; Sun, 7 Oct 2012 20:01:13 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 09FEA8FC08; Sun, 7 Oct 2012 20:01:12 +0000 (UTC) Received: from outgoing.leidinger.net (p5DD45BA9.dip.t-dialin.net [93.212.91.169]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 22468844006; Sun, 7 Oct 2012 22:01:06 +0200 (CEST) Received: from unknown (IO.Leidinger.net [192.168.1.12]) by outgoing.leidinger.net (Postfix) with ESMTPS id A54941F2D; Sun, 7 Oct 2012 22:01:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1349640063; bh=tW4CK7zHSMcgvnZHSNjxhbaldpGiLNCb0y28DjAJuHs=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=EY/o1NEjqlfcEnJLkg+OlO7O6O4Y2B6xuFkBEoCpx1Z2x+KzIZfqYLg3r3h1br2Hi Xglt0Pb8aXERzITOmRIwYE8Zt4LuqnegSktGYaSgK6fKmQn51M7lLZLke6i/UpzgDr YKd3RYe6qQCZVR3c2sparPtArrYnza5zX4mxZKinF3EgsxS+7W9keH/0vwYKoVvNOn X4J5794eqzEnsTs3UusRV89vZVkFy7a2SHsQcxLPysd7bH6TkPCaRYNYItmvrK0dCc Su2WKStTgMT3HiugvLjPSSYrENAkdikS5cbJMSvHOHjXMCMbERjL10oOCnv5uHYVK1 ehdfvzkPltlLw== Date: Sun, 7 Oct 2012 22:01:00 +0200 From: Alexander Leidinger To: Devin Teske Message-ID: <20121007220100.00002d21@unknown> In-Reply-To: References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <20121007183433.000026a6@unknown> X-Mailer: Claws Mail 3.8.0cvs30 (GTK+ 2.24.10; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 22468844006.AF3AE X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.574, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL -0.46, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1350244868.88508@I72YQrHxXawGnE4+FmDulQ X-EBL-Spam-Status: No Cc: devin.teske@fisglobal.com, 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 20:01:13 -0000 On Sun, 7 Oct 2012 11:44:25 -0700 Devin Teske wrote: > On Oct 7, 2012, at 9:34 AM, Alexander Leidinger wrote: > > > On Sat, 6 Oct 2012 16:48:50 -0700 Devin Teske > > wrote: > > > >> 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? > > > > IMO single user mode should be in the first level. I never had to > > use the other options, but I often used single-user mode. Another > > reson is that we tell to install the world in single-user mode. > > While I've always installed the world in multi-user mode, we should > > make it easy/fast to do it the recommended way. > > > > The documentation on how to get into single-user mode would need to > be changed from: > > Press 's' and 'ENTER' > > to instead: > > Press 'o' then 's' then 'ENTER' > Please note that 16+ months ago we had to update the documentation > for my last enhancement to the loader menu. It used to be: > > Press 's' > > and changed to: > > Press 's' then 'ENTER' I failed to notice this, due to lack of need to go into single-user mode since then respectively lack of need to have a look at the boot menu when booting. Please see below for my opinion of this. > because we went from a stateless menu system to a stateful menu > system. The driving force behind that was indeed the fact that with > the old stateless menu, you could not ever boot with > combinations-of-options (but rather you could only boot with options > that were presented -- unless of course you dropped to the > interactive prompt and did the dirty work yourself). Let me rephrase my previous mail a little bit: Personally I agree that safe mode and ACPI can be moved to a submenu, but single-user mode does not belong into the same submenu. While technically they may be similar (setting some options in the loader which based upon this does something behind the scenes), conceptually they are not the same thing for an user, so from an usability point of view they do not belong into the same submenu. IMO single-user mode shouldn't be an option, but a top-level item like "boot". Conceptually it falls within boot and reboot in my point of view (similar would be "boot from network" in case we would add this possibility to the loader). It's not really a small modification of the boot like with safe mode and verbose booting, it's big change in the outcome of the operation. You told in another mail that there is a technical limitation to the number of items, so I assume your interest in moving out as much options as possible is based upon this. You've already made room by moving 3 items out to the submenu. It would be great if "boot single-user" would be along boot and reboot, the rest can be put into a submenu. Even if we are challenged in the future regarding space, we can always put "More" (or similar) as a 5th item and have all the submenus behind "More". I've also seen your mail where you tell to think about the situation where a poor victim is sitting in front of FreeBSD as a remote hand. Having a top-level entry for single-user mode there and all the rest somewhere else would help in this situation too. It's not uncommon to ask a remote hand to boot to single-user, and this would clash with your hint at putting those other options out of the mind of the poor victim. So basically I propose something like this: Main menu: 1. Boot 2. Escape 3. Reboot 4. Boot to single-user mode 5. Expert options (order and numbering doesn't matter, feel free to shuffle around at will) Expert menu: 1. Boot options (what you have in the current submenu except single-user) 2. Change Root FS / BE / kernel to boot / whatever you name it (order and numbering... shuffle around at will) The rationale of having different submenus for changing the root FS and the other boot options are twofold. The first one is a tribute to the poor victim which gives a helping hand, he will not see the boot options in case the request is made to change the root FS. The second one is that the boot options are modifying the behavior of a given kernel (verbose messages, safe mode, acpi), while the root-fs/BE/kernel item is choosing a different kernel to boot. I'm trying to improve the usability / understandability of the boot process from an user point of view. I've tried to forget the technical details and tried to focus on action items an user / minion would like to do. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 20:01:31 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 9759010656CE; Sun, 7 Oct 2012 20:01:31 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 86BEB8FC16; Sun, 7 Oct 2012 20:01:28 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA16744; Sun, 07 Oct 2012 23:01:26 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TKx2U-0008ay-D3; Sun, 07 Oct 2012 23:01:26 +0300 Message-ID: <5071DF94.5010005@FreeBSD.org> Date: Sun, 07 Oct 2012 23:01:24 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120913 Thunderbird/15.0.1 MIME-Version: 1.0 To: Doug Barton References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <5071D6B5.1010609@FreeBSD.org> In-Reply-To: <5071D6B5.1010609@FreeBSD.org> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Devin Teske , 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 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:01:31 -0000 on 07/10/2012 22:23 Doug Barton said the following: > I think it would be much simpler to leave everything that is at > the top level now, and make submenus option number 8 I disagree about "everything". Safe Boot is open for changes. Because it's a big black box. ACPI option could go where the sub-options of Safe Mode go too. These two options are really troubleshooting options and are not interactively used once a system is installed and configured. -- Andriy Gapon 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. From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 20:34:19 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 CDE3210656C7; Sun, 7 Oct 2012 20:34:18 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 885298FC14; Sun, 7 Oct 2012 20:34:18 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so3817544pbb.13 for ; Sun, 07 Oct 2012 13:34:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=DIrROcnI5P7diiORGOOmdWOQvKAfwJ0mV4loCx5qavw=; b=Z8zeHIy9iJbUPI01ywYiELtXkl27Q6b+UMQ1sk+tpwjJOZGYfp1PHgTny4eq8D7yTe x63+b94VJrp6Q66i1xevICbB4G2N+a+ILQn5rBnOqkgPulwT767W9oRmGLP5Kxwvw1xN c09+bti0eEjPzjz6M8xD6szXhgWdf75eoA+YOE2IIsykWVz0q5yu15Q6kHfKfSvjD52R BraNpXFV/PezdcIefyDyyh7VjRg6TY+iIiTdg2NXDd7hOS4RLuddhxNuKd9RMTVdEwHn ws2MHqchjE3wiaP0c7zNL3twA4XPDsuFeUr6xRyJQH69dYju43uctmnLcanj8kqx6hGW YWZg== Received: by 10.68.227.162 with SMTP id sb2mr48641022pbc.4.1349642058193; Sun, 07 Oct 2012 13:34:18 -0700 (PDT) Received: from fuji-wireless.local (c-24-19-191-56.hsd1.wa.comcast.net. [24.19.191.56]) by mx.google.com with ESMTPS id c1sm9646211pay.19.2012.10.07.13.34.16 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 07 Oct 2012 13:34:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Garrett Cooper In-Reply-To: <5071DF94.5010005@FreeBSD.org> Date: Sun, 7 Oct 2012 13:35:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <5071D6B5.1010609@FreeBSD.org> <5071DF94.5010005@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1283) Cc: Devin Teske , Doug Barton , 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 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:34:19 -0000 On Oct 7, 2012, at 1:01 PM, Andriy Gapon wrote: > on 07/10/2012 22:23 Doug Barton said the following: >> I think it would be much simpler to leave everything that is at >> the top level now, and make submenus option number 8 >=20 > I disagree about "everything". Safe Boot is open for changes. = Because it's a > big black box. ACPI option could go where the sub-options of Safe = Mode go too. > These two options are really troubleshooting options and are not = interactively > used once a system is installed and configured. Windows featured multiple "Safe Boot" modes, one which contained = interactive prompts for enabling functionality. Maybe that would be a = good idea for newbs who need a Safe Mode walkthrough? Lol. -Garrett= From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 20:36:40 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 B48CC10656C5; Sun, 7 Oct 2012 20:36:40 +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 732F88FC20; Sun, 7 Oct 2012 20:36:40 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa03.fnfis.com (8.14.4/8.14.4) with ESMTP id q97KabvP027635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 7 Oct 2012 15:36:37 -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:36:37 -0500 MIME-Version: 1.0 (Apple Message framework v1283) From: Devin Teske In-Reply-To: Date: Sun, 7 Oct 2012 13:36:35 -0700 Message-ID: <0CB9F1EA-2176-4AE9-B899-6E8744D06DC7@fisglobal.com> References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <86k3v21qsx.fsf@ds4.des.no> <3EB58454-7820-43C4-911E-7DEF2D02C880@fisglobal.com> <86fw5q15f9.fsf@ds4.des.no> To: Garrett Cooper 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 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , 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:36:40 -0000 On Oct 7, 2012, at 12:52 PM, Garrett Cooper wrote: > On Oct 7, 2012, at 12:03 PM, Devin Teske wrote: >=20 >> On Oct 7, 2012, at 11:51 AM, Dag-Erling Sm=F8rgrav wrote: >>=20 >>> Devin Teske writes: >>>> Dag-Erling Sm=F8rgrav writes: >>>>> What problem are you trying to solve, exactly? >>>> Many in-fact: >>>> [list of things that bear no relation whatsoever to what was actually >>>> in the email I replied to] >>>=20 >>=20 >> I disagree with your slight that those "things =85 bear no relation what= soever to what was actually in the e-mail [you] replied to". >>=20 >> It only *seem* as those are unrelated. I assure you, they are _very_ rel= ated (and it's very much my mistake for not making it clear in my initial e= -mail). I must apologize for this lack of clarity (I try to rectify it belo= w). >>=20 >>> Then maybe you should have focused on that in your original email. >>>=20 >>=20 >> Yes, perhaps. >>=20 >> Perhaps it would have been better to explain: >>=20 >> Hey=85 >>=20 >> + iX and I are working on enhancing the boot loader menu to include a ne= w submenu for selecting a Boot Environment (BE). I'm providing the menu inf= rastructure, iX is providing the C code to populate that menu. >=20 > Sounds like GRUB/Plymouth's model... sorta. >=20 >> + We can't add this new menu item without pigeon-holing ourselves into a= position where no more menuitems can be added. >=20 > Understood. >=20 > ... > - Have you considered high resolution screens/fonts; there are some alrea= dy in FreeBSD hooked into syscons, but that's available later on at boot? I= mention this because there's a lot of wasted real estate on my 30" or 24" = LCDs when I boot up FreeBSD. >=20 Adding screen real-estate won't help. Menus (and any of the maximum 65535 s= ubmenus) are always limited to 9 maximum menu items. A significant overhaul of the Forth code would be required to accommodate m= ore than 9 menu items per-menu. Currently, if a 10th menuitem were rendered (assuming I lifted the boundary= -checks), it would be rendered as such: =85 8. Eighth Item 9. Ninth Item 1. Tenth item =85 Worse, you press "8" to invoke the 8th item, "9" to invoke the 9th item, bu= t ":" to invoke the 10th item (wait, what?) Yes, ":" to invoke the 10th item. Because currently ASCII keycodes are used= to associate menu items. The next character after "9" is ":". > I'd like to see sketches or a general idea of what you have in mind befor= e investing too much time in a direction that doesn't bear a lot of fruit. = I'm sure others here agree. >=20 Sorry, but I'm the infrastructure guy. I provide the framework. I'll leave = it to the community to decide how to use that framework. I'm leaving it in = jpaetzel's, avg's, and mav's very capable hands to utilize my framework in = whatever way they see fit. They came to me with a need. I filled that need. If the community doesn't w= ant it, I'll just dump it into DruidBSD and use it there until someone want= s it. --=20 DevinDe _____________ 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. From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 20:48:55 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 25A90106564A; Sun, 7 Oct 2012 20:48:55 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id E583F8FC0A; Sun, 7 Oct 2012 20:48:54 +0000 (UTC) Received: from JRE-MBP-2.local (c-50-143-149-146.hsd1.ca.comcast.net [50.143.149.146]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q97Kmpmp091400 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 7 Oct 2012 13:48:51 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5071EAB2.4060003@freebsd.org> Date: Sun, 07 Oct 2012 13:48:50 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Garrett Cooper References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <86k3v21qsx.fsf@ds4.des.no> <3EB58454-7820-43C4-911E-7DEF2D02C880@fisglobal.com> <86fw5q15f9.fsf@ds4.des.no> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: =?windows-1252?Q?rgrav?= , =?windows-1252?Q?Dag-Erling_Sm=F8?=, 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 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:48:55 -0000 On 10/7/12 12:52 PM, Garrett Cooper wrote: > I'd like to see sketches or a general idea of what you have in mind before investing too much time in a direction that doesn't bear a lot of fruit. I'm sure others here agree. It'd be interesting to see if we could get a boot loader that has an option to boot a backup image, or maybe off network.. I know that by the time we got this far we are supposed to be beyond that, but who knows what is actually possible. I'd love to see a picoBSD image available for booting in emergencies. Whether in it's own partition, or just a file in the root partition (or wherever) that can be loaded as a root filesystem. having the ability to recover from really bad screwups is why you need the menus in the first place usually. not sure what is really possible. From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 20:49:30 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 4879B1065687; Sun, 7 Oct 2012 20:49:30 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0AE0E8FC12; Sun, 7 Oct 2012 20:49:28 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so3823044pbb.13 for ; Sun, 07 Oct 2012 13:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=krORJAlJvVYIxvy0l2cZ/t4z/GXf7pP7PuqkNDifWaY=; b=J927MNEPZlSyKwdRt5nhZNyWk680kmtCNnwQmohKidzoRQT/nYZKxThuzp3Uc1QLrE EOEHlkNfUWXRYeR2Zs1uWaLsInMsUQzvdDtnvzugHOozEZtNzVW9VX+Ret7fA6OnARj8 cJBLs1CIaACjwwtKcEwmJVZ7AuCja0WXwNgNxxr7Qm+fS7gbvRzlMMtm/vOLf3rDA+Po o3WztUI8ykV1HbI0/5KM1EwEHBoLbqOs1kbfCL7EG83hji1EVV8JpQmEf4RPGUnof13Q lpn1HIq3ya0ebkUPEB8PQvW8DdtETGET07FfVPufaG+xoGk1Td2OszX2nmwsEB3hRO7V dUgA== Received: by 10.68.132.40 with SMTP id or8mr32610221pbb.63.1349642968079; Sun, 07 Oct 2012 13:49:28 -0700 (PDT) Received: from fuji-wireless.local (c-24-19-191-56.hsd1.wa.comcast.net. [24.19.191.56]) by mx.google.com with ESMTPS id vi9sm9545853pbc.41.2012.10.07.13.49.25 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 07 Oct 2012 13:49:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) From: Garrett Cooper In-Reply-To: <0CB9F1EA-2176-4AE9-B899-6E8744D06DC7@fisglobal.com> Date: Sun, 7 Oct 2012 13:50:12 -0700 Message-Id: References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <86k3v21qsx.fsf@ds4.des.no> <3EB58454-7820-43C4-911E-7DEF2D02C880@fisglobal.com> <86fw5q15f9.fsf@ds4.des.no> <0CB9F1EA-2176-4AE9-B899-6E8744D06DC7@fisglobal.com> To: Devin Teske X-Mailer: Apple Mail (2.1283) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , 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 20:49:30 -0000 On Oct 7, 2012, at 1:36 PM, Devin Teske wrote: > On Oct 7, 2012, at 12:52 PM, Garrett Cooper wrote: >=20 >> - Have you considered high resolution screens/fonts; there are some = already in FreeBSD hooked into syscons, but that's available later on at = boot? I mention this because there's a lot of wasted real estate on my = 30" or 24" LCDs when I boot up FreeBSD. >=20 > Adding screen real-estate won't help. Menus (and any of the maximum = 65535 submenus) are always limited to 9 maximum menu items. >=20 > A significant overhaul of the Forth code would be required to = accommodate more than 9 menu items per-menu. >=20 > Currently, if a 10th menuitem were rendered (assuming I lifted the = boundary-checks), it would be rendered as such: >=20 > =85 > 8. Eighth Item > 9. Ninth Item > 1. Tenth item > =85 >=20 > Worse, you press "8" to invoke the 8th item, "9" to invoke the 9th = item, but ":" to invoke the 10th item (wait, what?) >=20 > Yes, ":" to invoke the 10th item. Because currently ASCII keycodes are = used to associate menu items. The next character after "9" is ":". :(=85 Understood. >> I'd like to see sketches or a general idea of what you have in mind = before investing too much time in a direction that doesn't bear a lot of = fruit. I'm sure others here agree. >=20 > Sorry, but I'm the infrastructure guy. I provide the framework. I'll = leave it to the community to decide how to use that framework. I'm = leaving it in jpaetzel's, avg's, and mav's very capable hands to utilize = my framework in whatever way they see fit. >=20 > They came to me with a need. I filled that need. If the community = doesn't want it, I'll just dump it into DruidBSD and use it there until = someone wants it. Ok. I wasn't aware of the language constraints with Forth (I've dabbled = very briefly in it, but I am by no means even a novice), and now I = better understand some of the issues you're facing. Thanks for the explanation! I'll try to be more less critical next time. -Garrett= From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 20:49:55 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 D54F4106566B; Sun, 7 Oct 2012 20:49:55 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id AB20A8FC0A; Sun, 7 Oct 2012 20:49:55 +0000 (UTC) Received: from JRE-MBP-2.local (c-50-143-149-146.hsd1.ca.comcast.net [50.143.149.146]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q97Knl2v091409 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 7 Oct 2012 13:49:48 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5071EAEB.9090509@freebsd.org> Date: Sun, 07 Oct 2012 13:49:47 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Devin Teske References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <86k3v21qsx.fsf@ds4.des.no> <3EB58454-7820-43C4-911E-7DEF2D02C880@fisglobal.com> <86fw5q15f9.fsf@ds4.des.no> <0CB9F1EA-2176-4AE9-B899-6E8744D06DC7@fisglobal.com> In-Reply-To: <0CB9F1EA-2176-4AE9-B899-6E8744D06DC7@fisglobal.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Garrett Cooper , =?windows-1252?Q?Dag-Erling_Sm=F8rgrav?= , 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 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:49:55 -0000 On 10/7/12 1:36 PM, Devin Teske wrote: > On Oct 7, 2012, at 12:52 PM, Garrett Cooper wrote: > > > >> On Oct 7, 2012, at 12:03 PM, Devin Teske wrote: >> >>> On Oct 7, 2012, at 11:51 AM, Dag-Erling Smørgrav wrote: >>> >>>> Devin Teske writes: >>>>> Dag-Erling Smørgrav writes: >>>>>> What problem are you trying to solve, exactly? >>>>> Many in-fact: >>>>> [list of things that bear no relation whatsoever to what was actually >>>>> in the email I replied to] >>> I disagree with your slight that those "things … bear no relation whatsoever to what was actually in the e-mail [you] replied to". >>> >>> It only *seem* as those are unrelated. I assure you, they are _very_ related (and it's very much my mistake for not making it clear in my initial e-mail). I must apologize for this lack of clarity (I try to rectify it below). >>> >>>> Then maybe you should have focused on that in your original email. >>>> >>> Yes, perhaps. >>> >>> Perhaps it would have been better to explain: >>> >>> Hey… >>> >>> + iX and I are working on enhancing the boot loader menu to include a new submenu for selecting a Boot Environment (BE). I'm providing the menu infrastructure, iX is providing the C code to populate that menu. >> Sounds like GRUB/Plymouth's model... sorta. >> >>> + We can't add this new menu item without pigeon-holing ourselves into a position where no more menuitems can be added. >> Understood. >> >> ... >> - Have you considered high resolution screens/fonts; there are some already in FreeBSD hooked into syscons, but that's available later on at boot? I mention this because there's a lot of wasted real estate on my 30" or 24" LCDs when I boot up FreeBSD. >> > Adding screen real-estate won't help. Menus (and any of the maximum 65535 submenus) are always limited to 9 maximum menu items. > > A significant overhaul of the Forth code would be required to accommodate more than 9 menu items per-menu. > > Currently, if a 10th menuitem were rendered (assuming I lifted the boundary-checks), it would be rendered as such: > > … > 8. Eighth Item > 9. Ninth Item > 1. Tenth item A,B,C,D..... Z? > … > > Worse, you press "8" to invoke the 8th item, "9" to invoke the 9th item, but ":" to invoke the 10th item (wait, what?) > > Yes, ":" to invoke the 10th item. Because currently ASCII keycodes are used to associate menu items. The next character after "9" is ":". > > > >> I'd like to see sketches or a general idea of what you have in mind before investing too much time in a direction that doesn't bear a lot of fruit. I'm sure others here agree. >> > Sorry, but I'm the infrastructure guy. I provide the framework. I'll leave it to the community to decide how to use that framework. I'm leaving it in jpaetzel's, avg's, and mav's very capable hands to utilize my framework in whatever way they see fit. > > They came to me with a need. I filled that need. If the community doesn't want it, I'll just dump it into DruidBSD and use it there until someone wants it. From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 20:58:53 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 8F915106564A; Sun, 7 Oct 2012 20:58:53 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4C8518FC08; Sun, 7 Oct 2012 20:58:53 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so3826307pbb.13 for ; Sun, 07 Oct 2012 13:58:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=e/gVUY3H3sR6MxQ0U6t7QM3IUIbNLFJbjS1g2poymVg=; b=K7z+5CmXZIHkIzX3r+3cFNeG0KQChWBuORiJw+fIhD/ZwWVvOMaXXeYDuo6cWecrv4 Epwao474/6J7ryvQq0SB5hSVXafu+o3oZcOBF9LK1R5369h2gIVuN2AR5sT2/ShPLdHd EoMiEJn4Kh8UFuFPkV6dvq0aGWZdZKbKEErsxYVX4wZeH9mw4axtcxElDajBHzdxOGGz JQQzpO0G2Wa2sa1Avur9PJDmXsqyxdyfhh6uIwAcJbWOElOvEhHmMvgKskXK6sos2fGO PFEDmuxoRVqybmHamIJBqoEE/DAYb1U1fDKIQBUrcwOhYLWzE5ZwkEbBwVhQw0DSVkSf VZ6g== Received: by 10.68.201.104 with SMTP id jz8mr48456184pbc.141.1349643532869; Sun, 07 Oct 2012 13:58:52 -0700 (PDT) Received: from fuji-wireless.local (c-24-19-191-56.hsd1.wa.comcast.net. [24.19.191.56]) by mx.google.com with ESMTPS id gg6sm3266906pbc.38.2012.10.07.13.58.50 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 07 Oct 2012 13:58:51 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Garrett Cooper In-Reply-To: <5071EAEB.9090509@freebsd.org> Date: Sun, 7 Oct 2012 13:59:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <981AFB75-8A23-4CB1-906B-7E61D76A150B@gmail.com> References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <86k3v21qsx.fsf@ds4.des.no> <3EB58454-7820-43C4-911E-7DEF2D02C880@fisglobal.com> <86fw5q15f9.fsf@ds4.des.no> <0CB9F1EA-2176-4AE9-B899-6E8744D06DC7@fisglobal.com> <5071EAEB.9090509@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1283) Cc: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , Devin Teske , 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 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:58:53 -0000 On Oct 7, 2012, at 1:49 PM, Julian Elischer wrote: > On 10/7/12 1:36 PM, Devin Teske wrote: >> On Oct 7, 2012, at 12:52 PM, Garrett Cooper wrote: >>=20 >>> On Oct 7, 2012, at 12:03 PM, Devin Teske wrote: >>>=20 >>>> On Oct 7, 2012, at 11:51 AM, Dag-Erling Sm=F8rgrav wrote: >>>>=20 >>>>> Devin Teske writes: >>>>>> Dag-Erling Sm=F8rgrav writes: >>>>>>> What problem are you trying to solve, exactly? >>>>>> Many in-fact: >>>>>> [list of things that bear no relation whatsoever to what was = actually >>>>>> in the email I replied to] >>>> I disagree with your slight that those "things =85 bear no relation = whatsoever to what was actually in the e-mail [you] replied to". >>>>=20 >>>> It only *seem* as those are unrelated. I assure you, they are = _very_ related (and it's very much my mistake for not making it clear in = my initial e-mail). I must apologize for this lack of clarity (I try to = rectify it below). >>>>=20 >>>>> Then maybe you should have focused on that in your original email. >>>>>=20 >>>> Yes, perhaps. >>>>=20 >>>> Perhaps it would have been better to explain: >>>>=20 >>>> Hey=85 >>>>=20 >>>> + iX and I are working on enhancing the boot loader menu to include = a new submenu for selecting a Boot Environment (BE). I'm providing the = menu infrastructure, iX is providing the C code to populate that menu. >>> Sounds like GRUB/Plymouth's model... sorta. >>>=20 >>>> + We can't add this new menu item without pigeon-holing ourselves = into a position where no more menuitems can be added. >>> Understood. >>>=20 >>> ... >>> - Have you considered high resolution screens/fonts; there are some = already in FreeBSD hooked into syscons, but that's available later on at = boot? I mention this because there's a lot of wasted real estate on my = 30" or 24" LCDs when I boot up FreeBSD. >>>=20 >> Adding screen real-estate won't help. Menus (and any of the maximum = 65535 submenus) are always limited to 9 maximum menu items. >>=20 >> A significant overhaul of the Forth code would be required to = accommodate more than 9 menu items per-menu. >>=20 >> Currently, if a 10th menuitem were rendered (assuming I lifted the = boundary-checks), it would be rendered as such: >>=20 >> =85 >> 8. Eighth Item >> 9. Ninth Item >> 1. Tenth item >=20 > A,B,C,D..... Z? My mom would be confused with a user interface like that, but it would = sure be funny to watch :) (makes me feel like Sesame Street). -Garrett= From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 21:10:36 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 033BD106566C; Sun, 7 Oct 2012 21:10:36 +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 B51B98FC12; Sun, 7 Oct 2012 21:10:35 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa06.fnfis.com (8.14.4/8.14.4) with ESMTP id q97LAXfx010998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 7 Oct 2012 16:10:33 -0500 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.16) with Microsoft SMTP Server (TLS) id 14.2.309.2; Sun, 7 Oct 2012 16:10:32 -0500 MIME-Version: 1.0 (Apple Message framework v1283) From: Devin Teske In-Reply-To: <5071EAB2.4060003@freebsd.org> Date: Sun, 7 Oct 2012 14:10:29 -0700 Message-ID: References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <86k3v21qsx.fsf@ds4.des.no> <3EB58454-7820-43C4-911E-7DEF2D02C880@fisglobal.com> <86fw5q15f9.fsf@ds4.des.no> <5071EAB2.4060003@freebsd.org> To: Julian Elischer 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 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Garrett Cooper , =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , 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 21:10:36 -0000 On Oct 7, 2012, at 1:48 PM, Julian Elischer wrote: > On 10/7/12 12:52 PM, Garrett Cooper wrote: >> I'd like to see sketches or a general idea of what you have in mind befo= re investing too much time in a direction that doesn't bear a lot of fruit.= I'm sure others here agree. > It'd be interesting to see if we could get a boot loader that has an opti= on to boot a backup > image, or maybe off network.. I know that by the time we got this far we = are supposed to be > beyond that, but who knows what is actually possible. >=20 > I'd love to see a picoBSD image available for booting in emergencies. Whe= ther in it's own partition, > or just a file in the root partition (or wherever) that can be loaded as = a root filesystem. > having the ability to recover from really bad screwups is why you need th= e menus in the first place usually. >=20 > not sure what is really possible. >=20 *huge smiles* Have you been talking to old VICORians about what I've been working on here= ? haha It's like you stole a page out of my playbook. I've been working on this for years (slowly making the infrastructure chang= es in DruidBSD to accommodate this, and slowly trying to work that code bac= k into FreeBSD). NOTE: DruidBSD at it's core (when it's not being re-purposed as a multi-med= ia FreeBSD universal installation platform) is actually smaller than PicoBS= D. In the past month, I used DruidBSD maybe 5-dozen times to rescue an unboota= ble system. Which system? the system I was developing the boot loader on (h= aha). Everytime I would make a mistake (and subsequently end up in BTX halt, pani= c free guard1, or other fatal condition), I simply reboot, boot DruidBSD, a= nd within 3 keystrokes I have my system mounted read-write with all the too= ls I need to fix it. In less than 20 seconds, I've often corrected my mista= ke and have a working system again. NOTE: You can try it out yourself. I made publicly-available the latest ver= sion recently as part-of the FreeBSD-9.0_Druid-1.0b57.iso up on druidbsd.sf= .net (boot the ISO, select "freebsd", then select "Interactive Disk Repair = Shell" and answer guided questions to create a working environment copaceti= c to fixing even the worst situations). It even has a mode where it will st= art SSHD from the boot media so that *someone-ELSE* can log in remotely and= fix your non-bootable system (which we've had to use before -- it's a real= life-saver when someone in Manila for example has no FreeBSD knowledge but= can at least boot a system with a CD and answer some basic questions). Here's a screenshot that shows that DruidBSD has had the ability to swap ou= t the root filesystem image with a "rescue image" for nearly a decade (this= one screenshot taken 3 years ago): http://twitpic.com/16spp2 --=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. From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 21:13:18 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 25A421065673; Sun, 7 Oct 2012 21:13:18 +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 D95A88FC16; Sun, 7 Oct 2012 21:13:17 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa03.fnfis.com (8.14.4/8.14.4) with ESMTP id q97LDFds004103 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 7 Oct 2012 16:13:15 -0500 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.31) with Microsoft SMTP Server (TLS) id 14.2.309.2; Sun, 7 Oct 2012 16:13:14 -0500 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Devin Teske In-Reply-To: <5071EAEB.9090509@freebsd.org> Date: Sun, 7 Oct 2012 14:13:11 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <48E00D6E-B024-4130-92BA-70ECF1E88480@fisglobal.com> References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <86k3v21qsx.fsf@ds4.des.no> <3EB58454-7820-43C4-911E-7DEF2D02C880@fisglobal.com> <86fw5q15f9.fsf@ds4.des.no> <0CB9F1EA-2176-4AE9-B899-6E8744D06DC7@fisglobal.com> <5071EAEB.9090509@freebsd.org> To: Julian Elischer 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: Garrett Cooper , =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , 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 21:13:18 -0000 On Oct 7, 2012, at 1:49 PM, Julian Elischer wrote: > On 10/7/12 1:36 PM, Devin Teske wrote: >> On Oct 7, 2012, at 12:52 PM, Garrett Cooper wrote: >>=20 >>=20 >>=20 >>> On Oct 7, 2012, at 12:03 PM, Devin Teske wrote: >>>=20 >>>> On Oct 7, 2012, at 11:51 AM, Dag-Erling Sm=F8rgrav wrote: >>>>=20 >>>>> Devin Teske writes: >>>>>> Dag-Erling Sm=F8rgrav writes: >>>>>>> What problem are you trying to solve, exactly? >>>>>> Many in-fact: >>>>>> [list of things that bear no relation whatsoever to what was actually >>>>>> in the email I replied to] >>>> I disagree with your slight that those "things =85 bear no relation wh= atsoever to what was actually in the e-mail [you] replied to". >>>>=20 >>>> It only *seem* as those are unrelated. I assure you, they are _very_ r= elated (and it's very much my mistake for not making it clear in my initial= e-mail). I must apologize for this lack of clarity (I try to rectify it be= low). >>>>=20 >>>>> Then maybe you should have focused on that in your original email. >>>>>=20 >>>> Yes, perhaps. >>>>=20 >>>> Perhaps it would have been better to explain: >>>>=20 >>>> Hey=85 >>>>=20 >>>> + iX and I are working on enhancing the boot loader menu to include a = new submenu for selecting a Boot Environment (BE). I'm providing the menu i= nfrastructure, iX is providing the C code to populate that menu. >>> Sounds like GRUB/Plymouth's model... sorta. >>>=20 >>>> + We can't add this new menu item without pigeon-holing ourselves into= a position where no more menuitems can be added. >>> Understood. >>>=20 >>> ... >>> - Have you considered high resolution screens/fonts; there are some alr= eady in FreeBSD hooked into syscons, but that's available later on at boot?= I mention this because there's a lot of wasted real estate on my 30" or 24= " LCDs when I boot up FreeBSD. >>>=20 >> Adding screen real-estate won't help. Menus (and any of the maximum 6553= 5 submenus) are always limited to 9 maximum menu items. >>=20 >> A significant overhaul of the Forth code would be required to accommodat= e more than 9 menu items per-menu. >>=20 >> Currently, if a 10th menuitem were rendered (assuming I lifted the bound= ary-checks), it would be rendered as such: >>=20 >> =85 >> 8. Eighth Item >> 9. Ninth Item >> 1. Tenth item >=20 > A,B,C,D..... Z? >=20 I wasn't implying that this wasn't possible, just that it's not designed th= is way currently. It would be a significant overhaul to support this (_and_ we'd then have to= scramble for screen real-estate to support up to 35 menu items -- or perha= ps more generically support scrolling menus -- though I'm sure that can't b= e pleasing for the serial console folks to hear). --=20 Devin >> =85 >>=20 >> Worse, you press "8" to invoke the 8th item, "9" to invoke the 9th item,= but ":" to invoke the 10th item (wait, what?) >>=20 >> Yes, ":" to invoke the 10th item. Because currently ASCII keycodes are u= sed to associate menu items. The next character after "9" is ":". >>=20 >>=20 >>=20 >>> I'd like to see sketches or a general idea of what you have in mind bef= ore investing too much time in a direction that doesn't bear a lot of fruit= . I'm sure others here agree. >>>=20 >> Sorry, but I'm the infrastructure guy. I provide the framework. I'll lea= ve it to the community to decide how to use that framework. I'm leaving it = in jpaetzel's, avg's, and mav's very capable hands to utilize my framework = in whatever way they see fit. >>=20 >> They came to me with a need. I filled that need. If the community doesn'= t want it, I'll just dump it into DruidBSD and use it there until someone w= ants it. >=20 _____________ 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. From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 21:58:50 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 002AC1065675; Sun, 7 Oct 2012 21:58:49 +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 B66AE8FC1A; Sun, 7 Oct 2012 21:58:49 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa05.fnfis.com (8.14.4/8.14.4) with ESMTP id q97LwnLY003339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 7 Oct 2012 16:58:49 -0500 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.31) with Microsoft SMTP Server (TLS) id 14.2.309.2; Sun, 7 Oct 2012 16:58:48 -0500 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Devin Teske In-Reply-To: <20121007220100.00002d21@unknown> Date: Sun, 7 Oct 2012 14:58:46 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <20121007183433.000026a6@unknown> <20121007220100.00002d21@unknown> To: Alexander Leidinger 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 21:58:50 -0000 On Oct 7, 2012, at 1:01 PM, Alexander Leidinger wrote: > On Sun, 7 Oct 2012 11:44:25 -0700 Devin Teske > wrote: >=20 >> On Oct 7, 2012, at 9:34 AM, Alexander Leidinger wrote: >>=20 >>> On Sat, 6 Oct 2012 16:48:50 -0700 Devin Teske >>> wrote: >>>=20 >>>> 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 >>>>=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 >>>>=20 >>>> What does everybody think? >>>=20 >>> IMO single user mode should be in the first level. I never had to >>> use the other options, but I often used single-user mode. Another >>> reson is that we tell to install the world in single-user mode. >>> While I've always installed the world in multi-user mode, we should >>> make it easy/fast to do it the recommended way. >>>=20 >>=20 >> The documentation on how to get into single-user mode would need to >> be changed from: >>=20 >> Press 's' and 'ENTER' >>=20 >> to instead: >>=20 >> Press 'o' then 's' then 'ENTER' >=20 >> Please note that 16+ months ago we had to update the documentation >> for my last enhancement to the loader menu. It used to be: >>=20 >> Press 's' >>=20 >> and changed to: >>=20 >> Press 's' then 'ENTER' >=20 > I failed to notice this, due to lack of need to go into single-user > mode since then respectively lack of need to have a look at the boot > menu when booting. Please see below for my opinion of this. >=20 >> because we went from a stateless menu system to a stateful menu >> system. The driving force behind that was indeed the fact that with >> the old stateless menu, you could not ever boot with >> combinations-of-options (but rather you could only boot with options >> that were presented -- unless of course you dropped to the >> interactive prompt and did the dirty work yourself). >=20 > Let me rephrase my previous mail a little bit: >=20 > Personally I agree that safe mode and ACPI can be moved to a submenu, > but single-user mode does not belong into the same submenu. >=20 > While technically they may be similar (setting some options in the > loader which based upon this does something behind the scenes), > conceptually they are not the same thing for an user, so from an > usability point of view they do not belong into the same submenu. >=20 How right you are. > IMO single-user mode shouldn't be an option, but a top-level item like > "boot". Conceptually it falls within boot and reboot in my point of > view (similar would be "boot from network" in case we would add this > possibility to the loader). It's not really a small modification of the > boot like with safe mode and verbose booting, it's big change in the > outcome of the operation. >=20 You really hit it home with this one, I believe. > You told in another mail that there is a technical limitation to the > number of items, so I assume your interest in moving out as much > options as possible is based upon this. You've already made room by > moving 3 items out to the submenu. It would be great if "boot > single-user" would be along boot and reboot, the rest can be put into a > submenu. Even if we are challenged in the future regarding space, we > can always put "More" (or similar) as a 5th item and have all the > submenus behind "More". >=20 Absolutely! Talking further about the "More" concept, I used to lie awake at night wond= ering, "what if there are more than a handful of devices to display in a me= nu w/respect to the ``select root device'' proposition". I came to the same= conclusion=85 the last menu item is a "more" (after all, the latest enhanc= ement brings in support for 65535 submenus, which ought to be enough "more"= functionality to enumerate all devices in even the beefiest of systems). Hanging the same logic onto the "Options" and/or "Expert Options" functiona= lity is downright logical. I like it. > I've also seen your mail where you tell to think about the situation > where a poor victim is sitting in front of FreeBSD as a remote hand. > Having a top-level entry for single-user mode there and all the rest > somewhere else would help in this situation too. It's not uncommon to > ask a remote hand to boot to single-user, and this would clash with > your hint at putting those other options out of the mind of the poor > victim. >=20 You make a great point. In that spirit, I do very much like the idea of hav= ing "Boot Single =85" in the "actions" section atop the main menu. > So basically I propose something like this: >=20 > Main menu: > 1. Boot > 2. Escape > 3. Reboot > 4. Boot to single-user mode > 5. Expert options > (order and numbering doesn't matter, feel free to shuffle around at > will) I like the ordering. I also like the fact that you took care to handle the edge-case that they "= meant to hit #1 but hit #2 by accident". If the single-user mode option was= #2, they'd end up at a SUM prompt (and if they are unaware that they hit #= 2 by accident, they _may_ think their FreeBSD is b0rk3d). Opposed to the ab= ove ordering, if they hit #2 by accident when they meant to hit #1, no harm= (they're given a message stating "type menu and hit ENTER to get back to t= he menu" before being dumped to the interactive loader prompt). The ordering is good. I feel it. >=20 > Expert menu: > 1. Boot options (what you have in the current submenu except > single-user) > 2. Change Root FS / BE / kernel to boot / whatever you name it > (order and numbering... shuffle around at will) >=20 > The rationale of having different submenus for changing the root FS and > the other boot options are twofold. I wholly agree. > The first one is a tribute to the > poor victim which gives a helping hand, he will not see the boot > options in case the request is made to change the root FS. The second > one is that the boot options are modifying the behavior of a given > kernel (verbose messages, safe mode, acpi), while the root-fs/BE/kernel > item is choosing a different kernel to boot. >=20 I wholly agree with the separation into 2 submenus and _why_, however... Let's be careful here. Be careful to not include "kernel" in that mix. In reality, the kernel is loaded by the "start" FICL word provided by loade= r.4th and this is done: a. before the menu is loaded and b. irrespective of the menu (done regardless of whether the menu is enabled= or not, perhaps via setting beastie_disable=3DYES in loader.conf(5)) So by the time the menu is invoked, the only way to change the kernel is to= "unload" and subsequently load the new kernel. It should be noted that DruidBSD does not load a kernel before the menu. Th= us in DruidBSD, we _do_ have a kernel selection menu (the overloaded "boot"= FICL word in DruidBSD is coded to load $kernel right before doing the real= boot whereas FreeBSD's overloaded "boot" FICL word simply invokes the alre= ady-loaded kernel that was loaded before the menu ever started). Many people over the years (in passing) have asked me about whether FreeBSD= could support a kernel selection menu to allow easily running (say, for ex= ample) "kernel.old". I don't always answer with the full breadth of this th= read, but the answer is always "sure, that's very do-able" when in reality = (as I state here and now in this thread) the fundamental fact that FreeBSD = always loads $kernel (as configured in loader.conf(5)) prior to starting th= e menu has to change before this can become a possibility. It's perhaps good that we're having this discussion out in the open now, be= cause I actually (as of yet) do not know if jpaetzel, avg, mav and iX compa= ny have plans to (attempt) to allow kernel swapping in the loader menu. If = that is the case, we'll have to broach the topic of changing that functiona= lity to match what DruidBSD does (defers kernel loading until "boot" is inv= oked). > I'm trying to improve the usability / understandability of the boot > process from an user point of view. Awesome! Something I agree is worthwhile. > I've tried to forget the technical > details and tried to focus on action items an user / minion would like > to do. >=20 Thank you! I think we'll all benefit from this endeavor of discussing these= enhancements in such a clear state. --=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. From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 22:33:42 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 D6508106564A; Sun, 7 Oct 2012 22:33:42 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 92CA68FC0A; Sun, 7 Oct 2012 22:33:42 +0000 (UTC) Received: from JRE-MBP-2.local (c-50-143-149-146.hsd1.ca.comcast.net [50.143.149.146]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q97MXVA3093647 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 7 Oct 2012 15:33:32 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5072033A.4090308@freebsd.org> Date: Sun, 07 Oct 2012 15:33:30 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Devin Teske References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <86k3v21qsx.fsf@ds4.des.no> <3EB58454-7820-43C4-911E-7DEF2D02C880@fisglobal.com> <86fw5q15f9.fsf@ds4.des.no> <5071EAB2.4060003@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Garrett Cooper , =?windows-1252?Q?Dag-Erling_Sm=F8rgrav?= , 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 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 22:33:42 -0000 On 10/7/12 2:10 PM, Devin Teske wrote: > > On Oct 7, 2012, at 1:48 PM, Julian Elischer wrote: > >> On 10/7/12 12:52 PM, Garrett Cooper wrote: >>> I'd like to see sketches or a general idea of what you have in >>> mind before investing too much time in a direction that doesn't >>> bear a lot of fruit. I'm sure others here agree. >> It'd be interesting to see if we could get a boot loader that has >> an option to boot a backup >> image, or maybe off network.. I know that by the time we got this >> far we are supposed to be >> beyond that, but who knows what is actually possible. >> >> I'd love to see a picoBSD image available for booting in >> emergencies. Whether in it's own partition, >> or just a file in the root partition (or wherever) that can be >> loaded as a root filesystem. >> having the ability to recover from really bad screwups is why you >> need the menus in the first place usually. >> >> not sure what is really possible. >> > > *huge smiles* > > Have you been talking to old VICORians about what I've been working > on here? haha > > It's like you stole a page out of my playbook. > > I've been working on this for years (slowly making the > infrastructure changes in DruidBSD to accommodate this, and slowly > trying to work that code back into FreeBSD). > > NOTE: DruidBSD at it's core (when it's not being re-purposed as a > multi-media FreeBSD universal installation platform) is actually > smaller than PicoBSD. Pico, or Nano? I know that Pico no longer fits on a single floppy but it's still pretty damned small. > > In the past month, I used DruidBSD maybe 5-dozen times to rescue an > unbootable system. Which system? the system I was developing the > boot loader on (haha). so, the question is, were does the boot come from and where does it load the image from? usb-key? > > Everytime I would make a mistake (and subsequently end up in BTX > halt, panic free guard1, or other fatal condition), I simply reboot, > boot DruidBSD, and within 3 keystrokes I have my system mounted > read-write with all the tools I need to fix it. In less than 20 > seconds, I've often corrected my mistake and have a working system > again. to some extent I'd like to see some recoverability like this for default freeBSD. even the old "create a bootable usb fixit-key" during install might be enough. (keep it in an envelope taped to the side of the machine :-). > > NOTE: You can try it out yourself. I made publicly-available the > latest version recently as part-of the FreeBSD-9.0_Druid-1.0b57.iso > up on druidbsd.sf.net (boot the ISO, select > "freebsd", then select "Interactive Disk Repair Shell" and answer > guided questions to create a working environment copacetic to fixing > even the worst situations). It even has a mode where it will start > SSHD from the boot media so that *someone-ELSE* can log in remotely > and fix your non-bootable system (which we've had to use before -- > it's a real life-saver when someone in Manila for example has no > FreeBSD knowledge but can at least boot a system with a CD and > answer some basic questions). true, though I'd like to see if it can be done without the whole extra CD.. > > Here's a screenshot that shows that DruidBSD has had the ability to > swap out the root filesystem image with a "rescue image" for nearly > a decade (this one screenshot taken 3 years ago): > > http://twitpic.com/16spp2 > > -- > 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. From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 22:39:48 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 9D2321065673; Sun, 7 Oct 2012 22:39:48 +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 6704B8FC08; Sun, 7 Oct 2012 22:39:47 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa01.fnfis.com (8.14.4/8.14.4) with ESMTP id q97MdlvG021802 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 7 Oct 2012 17:39:47 -0500 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.15) with Microsoft SMTP Server (TLS) id 14.2.309.2; Sun, 7 Oct 2012 17:39:46 -0500 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Apple Message framework v1283) From: Devin Teske Date: Sun, 7 Oct 2012 15:39:45 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: To: 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 Subject: Tell the user we're booting 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 22:39:48 -0000 Hi, I'd like to propose a small (tiny even) patch to sys/boot/forth/loader.4th Said patch will echo "Booting=85" before invoking the kernel. This patch would effect every architecture (even those that don't use the b= eastie menu). The reason for proposing this tiny change is that as of 9.0-R I've noticed = a significant lag between executing "boot" and getting something on-screen = to show that something is happening. On my circa 2006 white Macbook (Intel, 4GB of RAM) running VMware Fusion 5,= FreeBSD 9.0-R GENERIC kernel takes on-average 3.76 seconds from the point = I hit ENTER on the "boot" command to the point that kernel messages start a= ppearing on-screen. I've had this patch applied to DruidBSD for almost a decade but have neglec= ted to request this enhancement for FreeBSD. Largely because it wasn't need= ed, but now that I'm seeing significant delays on older hardware (with GENE= RIC), I feel it dramatically increases perceived performance (simply by pro= viding feedback -- doubly important in the menu environment where the user = hits ENTER and nothing happens for 3-4 seconds). --=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. From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 22:48:18 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 F1BD4106564A; Sun, 7 Oct 2012 22:48:17 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id AD9FD8FC0C; Sun, 7 Oct 2012 22:48:17 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id z9so1355642dad.13 for ; Sun, 07 Oct 2012 15:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=vq/AjXrSpV9VyFi3SstzJgRGWfsP/vMukQ5fbiIyp+U=; b=omtnumdTtALYFcd91997sPvFH0B+DkOolwIeK6OAyV1E5X7WTqj66kIo6fApwz4UYp JNngmNQwUz/YSK14Uwtb8hhdLr93arou+86jwAPZxDvyxLjBfx9DDeyn2nk3eHCwNlEy RAoDVHM7Ew2GdiTyl0gbMsZfoIsYo9IUtST4ajNbaJrE4meL3Wi6Xcf6uU4sKbfoGhRp FvZnzRlXryd5i1rljSjBR/DBIPN/ouYuBwthCBMwxWUtKX7638gtJ9OVMcD+0x//o4oe SSj3NjHUiy5SvRxj4kLEP+LOrq8FN6/jV5SpJMeKELh1tD9pjng4MPQJYAne8j1ia9tt 3dpw== Received: by 10.68.233.230 with SMTP id tz6mr36522627pbc.36.1349650096873; Sun, 07 Oct 2012 15:48:16 -0700 (PDT) Received: from fuji-wireless.local (c-24-19-191-56.hsd1.wa.comcast.net. [24.19.191.56]) by mx.google.com with ESMTPS id e9sm9773012pay.34.2012.10.07.15.48.11 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 07 Oct 2012 15:48:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Garrett Cooper In-Reply-To: <5072033A.4090308@freebsd.org> Date: Sun, 7 Oct 2012 15:48:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <86k3v21qsx.fsf@ds4.des.no> <3EB58454-7820-43C4-911E-7DEF2D02C880@fisglobal.com> <86fw5q15f9.fsf@ds4.des.no> <5071EAB2.4060003@freebsd.org> <5072033A.4090308@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1283) Cc: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , Devin Teske , 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 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 22:48:18 -0000 On Oct 7, 2012, at 3:33 PM, Julian Elischer wrote: > Pico, or Nano? > I know that Pico no longer fits on a single floppy but it's still = pretty damned small. Have to be Pico. Nano is still too big by default (unless you pull = almost every feature and non-essential piece, the lowest I've gotten a = running image so far is 124MB unpacked with a GENERIC kernel. Granted, = if it wasn't GENERIC that would save 10~20 MB, but there are still other = things that need to be trimmed from the base system (another effort for = another day/thread). ... > true, though I'd like to see if it can be done without the whole extra = CD.. Should be doable with a ~64MB USB stick. I did an ok job [without = NanoBSD/PicoBSD] creating a thin client with X11 with ~140MB space used = and I wasn't trying terribly hard to pare things down (especially if = it's a compressed mfsroot :]=85). -Garrett= From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 22:52:43 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 2E281106566C; Sun, 7 Oct 2012 22:52:43 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id EB5368FC1A; Sun, 7 Oct 2012 22:52:42 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id z9so1356731dad.13 for ; Sun, 07 Oct 2012 15:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ipb15ngoBFeBhIrg0YxUWfK8rJW8dPfPjViLnf4XPfw=; b=jyRVNvAfVX8N1DX25idOo5oIHXoccoo9UT8GwIrPYiEciGNHljqNVbl7UIMlu5bdFJ HB/t+rBdbsMkHVcZ5VdYFSYhKgCxyL8ztW0v62UoG2ZzKBUSYqodfnJWKydFNs3djjNY uFSkzapoikqCjnD+qy8EwVKEd3Ra0QbIeRw08pyNS1GcGORiDkZlqBr9oQPBBM+IuNYr P0pwQ/SuebEO8gSO9EQ+sFL5TkhqHVNDvv4roztILDQhuQKCk6v4dyFUsfbGY/ezR1M6 Adf/CVMrzaWVi1szv8BrzCyqX59Iuh7FbOBQJS/LI1Ky+xexH3nbJ9LQaz9cn1nCBNvm QOkQ== Received: by 10.68.204.2 with SMTP id ku2mr48743837pbc.59.1349650362567; Sun, 07 Oct 2012 15:52:42 -0700 (PDT) Received: from fuji-wireless.local (c-24-19-191-56.hsd1.wa.comcast.net. [24.19.191.56]) by mx.google.com with ESMTPS id sj5sm9665805pbc.30.2012.10.07.15.52.40 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 07 Oct 2012 15:52:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Garrett Cooper In-Reply-To: Date: Sun, 7 Oct 2012 15:53:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Devin Teske X-Mailer: Apple Mail (2.1283) Cc: freebsd-arch@freebsd.org Subject: Re: Tell the user we're booting 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 22:52:43 -0000 On Oct 7, 2012, at 3:39 PM, Devin Teske wrote: > Hi, >=20 > I'd like to propose a small (tiny even) patch to = sys/boot/forth/loader.4th >=20 > Said patch will echo "Booting=85" before invoking the kernel. >=20 > This patch would effect every architecture (even those that don't use = the beastie menu). >=20 > The reason for proposing this tiny change is that as of 9.0-R I've = noticed a significant lag between executing "boot" and getting something = on-screen to show that something is happening. This is probably the memory test (set "hw.memtest.tests" to "0" = in loader.conf and see if that speeds things up). Regardless, I think = it'd be a good thing to have. Thanks! -Garrett PS Got patch?= From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 23:10:36 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 0233C106566B; Sun, 7 Oct 2012 23:10:36 +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 B73048FC08; Sun, 7 Oct 2012 23:10:35 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa03.fnfis.com (8.14.4/8.14.4) with ESMTP id q97NAYa4008799 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 7 Oct 2012 18:10:34 -0500 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.16) with Microsoft SMTP Server (TLS) id 14.2.309.2; Sun, 7 Oct 2012 18:10:34 -0500 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/mixed; boundary="Apple-Mail=_293A43D5-87B6-4CBC-A47B-F6BDE3C45D69" From: Devin Teske In-Reply-To: Date: Sun, 7 Oct 2012 16:10:31 -0700 Message-ID: <6DBE2255-40A3-452B-A503-04AF6A3FBE42@fisglobal.com> References: To: Garrett Cooper 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: Tell the user we're booting 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 23:10:36 -0000 --Apple-Mail=_293A43D5-87B6-4CBC-A47B-F6BDE3C45D69 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252" On Oct 7, 2012, at 3:53 PM, Garrett Cooper wrote: > On Oct 7, 2012, at 3:39 PM, Devin Teske wrote: >=20 >> Hi, >>=20 >> I'd like to propose a small (tiny even) patch to sys/boot/forth/loader.4= th >>=20 >> Said patch will echo "Booting=85" before invoking the kernel. >>=20 >> This patch would effect every architecture (even those that don't use th= e beastie menu). >>=20 >> The reason for proposing this tiny change is that as of 9.0-R I've notic= ed a significant lag between executing "boot" and getting something on-scre= en to show that something is happening. >=20 > This is probably the memory test (set "hw.memtest.tests" to "0" in loade= r.conf and see if that speeds things up). Regardless, I think it'd be a goo= d thing to have. > Thanks! > -Garrett >=20 > PS Got patch? Here's patch: _____________ 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. --Apple-Mail=_293A43D5-87B6-4CBC-A47B-F6BDE3C45D69 Content-Disposition: attachment; filename="patch.txt" Content-Type: text/plain; name="patch.txt" Content-Transfer-Encoding: 7bit Index: color.4th.8 =================================================================== --- color.4th.8 (revision 241310) +++ color.4th.8 (working copy) @@ -50,7 +50,7 @@ .Dl include color.4th .Pp This line is present in -.Pa /boot/beastie.4th +.Pa /boot/loader.4th file, so it is not needed (and should not be re-issued) in a normal setup. .Pp The commands provided by it are: @@ -102,7 +102,6 @@ .Sh SEE ALSO .Xr loader.conf 5 , .Xr loader 8 , -.Xr beastie.4th 8 , .Xr loader.4th 8 .Sh HISTORY The Index: loader.4th =================================================================== --- loader.4th (revision 241310) +++ loader.4th (working copy) @@ -40,6 +40,7 @@ 2048 dictincrease ! \ 2048 additional cells each time include /boot/support.4th +include /boot/color.4th only forth also support-functions also builtins definitions @@ -64,6 +65,12 @@ : boot 0= if ( interpreted ) get_arguments then + loader_color? if + ." Booting..." cr + else + ." Booting..." cr + then + \ Unload only if a path was passed dup if >r over r> swap Index: beastie.4th =================================================================== --- beastie.4th (revision 241310) +++ beastie.4th (working copy) @@ -28,7 +28,6 @@ marker task-beastie.4th -include /boot/color.4th include /boot/delay.4th variable logoX --Apple-Mail=_293A43D5-87B6-4CBC-A47B-F6BDE3C45D69-- From owner-freebsd-arch@FreeBSD.ORG Sun Oct 7 23:21:07 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 CDCB31065670; Sun, 7 Oct 2012 23:21:07 +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 8739A8FC0A; Sun, 7 Oct 2012 23:21:07 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa06.fnfis.com (8.14.4/8.14.4) with ESMTP id q97NL3B6030846 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 7 Oct 2012 18:21:03 -0500 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.31) with Microsoft SMTP Server (TLS) id 14.2.309.2; Sun, 7 Oct 2012 18:21:01 -0500 MIME-Version: 1.0 (Apple Message framework v1283) From: Devin Teske In-Reply-To: <5072033A.4090308@freebsd.org> Date: Sun, 7 Oct 2012 16:20:59 -0700 Message-ID: <338616C0-F1EC-409B-B044-ADBB62ECFE38@fisglobal.com> References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <86k3v21qsx.fsf@ds4.des.no> <3EB58454-7820-43C4-911E-7DEF2D02C880@fisglobal.com> <86fw5q15f9.fsf@ds4.des.no> <5071EAB2.4060003@freebsd.org> <5072033A.4090308@freebsd.org> To: Julian Elischer 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 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Garrett Cooper , =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , 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 23:21:07 -0000 On Oct 7, 2012, at 3:33 PM, Julian Elischer wrote: > On 10/7/12 2:10 PM, Devin Teske wrote: >>=20 >> On Oct 7, 2012, at 1:48 PM, Julian Elischer wrote: >>=20 >>> On 10/7/12 12:52 PM, Garrett Cooper wrote: >>>> I'd like to see sketches or a general idea of what you have in mind be= fore investing too much time in a direction that doesn't bear a lot of frui= t. I'm sure others here agree. >>> It'd be interesting to see if we could get a boot loader that has an op= tion to boot a backup >>> image, or maybe off network.. I know that by the time we got this far w= e are supposed to be >>> beyond that, but who knows what is actually possible. >>>=20 >>> I'd love to see a picoBSD image available for booting in emergencies. W= hether in it's own partition, >>> or just a file in the root partition (or wherever) that can be loaded a= s a root filesystem. >>> having the ability to recover from really bad screwups is why you need = the menus in the first place usually. >>>=20 >>> not sure what is really possible. >>>=20 >>=20 >> *huge smiles* >>=20 >> Have you been talking to old VICORians about what I've been working on h= ere? haha >>=20 >> It's like you stole a page out of my playbook. >>=20 >> I've been working on this for years (slowly making the infrastructure ch= anges in DruidBSD to accommodate this, and slowly trying to work th= at code back into FreeBSD). >>=20 >> NOTE: DruidBSD at it's core (when it's not being re-purposed as a multi-= media FreeBSD universal installation platform) is actually smaller than Pic= oBSD. >=20 > Pico, or Nano? > I know that Pico no longer fits on a single floppy but it's still pretty = damned small. >=20 The DruidBSD core image is a 1.9MB gzip-compressed floppy image (mfsroot.gz= ). NOTE: Of course, that doesn't include a kernel. When you get it all assembl= ed, it's still under 24MB (tho I could make that much smaller if I really w= anted). Funny story: Our company handed out 32MB (!!) thumb drives a couple years ago (yes, in 2= 010 !! they handed out 32MB !! thumb drives). Being almost completely usele= ss for any other means, I decided (no, _set out_) to create the _most_ usef= ul boot device possible from these paltry 32MB storage devices (which other= wise would have ended up in the trash). I successfully loaded DruidBSD _and= _ about 10 other great tools onto it (including memtest, windiag, memtest+,= seatools, dban, firmware updates, hdt, spinrite, tuff-test pro, and more);= everything easily usable with a graphical menu (using ISOLINUX and the ves= amenu com32 module) -- all still under the 32MB mark. An earlier version (sans corporate property, of course, such as spinrite an= d tuff-test pro enterprise-licensed copies) can be downloaded here: http://druidbsd.sourceforge.net/download.shtml#DruidBSD >>=20 >> In the past month, I used DruidBSD maybe 5-dozen times to rescue an unbo= otable system. Which system? the system I was developing the boot loader on= (haha). >=20 > so, the question is, were does the boot come from and where does it load = the image from? usb-key? I'd recommend keeping it in /boot However, for situations where you can't trust /boot you really would want t= o have an external device (with it's own copy of the boot files -- as in su= ch situations, you really can't trust _anything_ in /boot so you'd _want_ t= he external device to be your boot device with its own pristine copies). I'd say FreeBSD could use both: a. menu system that can load (for example) a /boot/rescue_mfsroot.gz in tim= es-of-need b. a small, tiny ISO with the same rescue scripts as rescue_mfsroot.gz in t= imes-of-need when /boot can't be trusted For (b) above, sure we have "-bootonly" media, but it's not imbued with any= scripts like what DruidBSD has (see http://druidbsd.cvs.sourceforge.net/vi= ewvc/druidbsd/druidbsd/druid/src/freebsd/menu/scripts/repair?revision=3D1.2= &view=3Dmarkup for the actual script I'm talking about) Rather, for (b) I'm talking about having an ISO that anybody in-need can do= wnload where said ISO is (a) small (b) built for rescue duty of any hardwar= e in any shape. Of course, there's no reason why the -bootonly media couldn't _become_ that= rescue disc with a little work. >>=20 >> Everytime I would make a mistake (and subsequently end up in BTX halt, p= anic free guard1, or other fatal condition), I simply reboot, boot DruidBSD= , and within 3 keystrokes I have my system mounted read-write with all the = tools I need to fix it. In less than 20 seconds, I've often corrected my mi= stake and have a working system again. >=20 > to some extent I'd like to see some recoverability like this for default = freeBSD. even the old "create a bootable usb fixit-key" during install mig= ht be enough. > (keep it in an envelope taped to the side of the machine :-). >=20 Definitely on the radar. I've even talked (briefly) with jpaetzel about thi= s. A lot of DruidBSD is all about building a better/smarter install platform t= hat has integrated automation, rescue, and cloning abilities. I'd really li= ke to see FreeBSD's installer (whatever that may be; currently bsdinstall) = embrace some of the pc-sysinstall features that jpaetzel and I talked about= in our last meeting. Such as the ability to boot a system from external me= dia, run a tool to detail the filesystem configuration, and then save that = config to a file for later use (either in setting up a machine with the sam= e characteristics or as a means of rescuing the same box in trying times). My plan is to (some day) hunker down and use bsdinstall and bsdconfig to ac= hieve this. However it's going to be a long process. Part of this long process is going to be the enhancements to the loader men= u that this thread has talked so much about. Another large part of this pro= cess is going to be simply bringing back the ability to use an mfsroot (som= ething that was lost-in-transition from 8 to 9). There are a LOT of systemic things that need to be broached before we can g= et to the promised land of integrated rescue (I've even envisaged the chang= es necessary at the release engineering level). But, =85 for now, DruidBSD is there for all of us to lean-on (and I'll cont= inue to release new/more-interesting DruidBSD products -- such as the micro= -rescue-image we're talking about here). >>=20 >> NOTE: You can try it out yourself. I made publicly-available the latest = version recently as part-of the FreeBSD-9.0_Druid-1.0b57.iso up on druidbsd= .sf.net (boot the ISO, select "freebsd", then select "Interactive Disk Repa= ir Shell" and answer guided questions to create a working environment copac= etic to fixing even the worst situations). It even has a mode where it will= start SSHD from the boot media so that *someone-ELSE* can log in remotely = and fix your non-bootable system (which we've had to use before -- it's a r= eal life-saver when someone in Manila for example has no FreeBSD knowledge = but can at least boot a system with a CD and answer some basic questions). > true, though I'd like to see if it can be done without the whole extra CD= .. >=20 Right-o. I'm telling people in the above, that if they want to try out this= "rescue functionality" (which _doesn't_ require a whole extra CD) they cur= rently _must_ use a whole extra CD because the "rescue_mfsroot.gz" hasn't b= een published "in the raw" (but if you dig in CVSweb you can download it di= rectly for inspection). --=20 Devin >>=20 >> Here's a screenshot that shows that DruidBSD has had the ability to swap= out the root filesystem image with a "rescue image" for nearly a decade (t= his one screenshot taken 3 years ago): >>=20 >> http://twitpic.com/16spp2 >>=20 >> --=20 >> Devin >> _____________ >> The information contained in this message is proprietary and/or confiden= tial. 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 aw= are that any message addressed to our domain is subject to archiving and re= view by persons other than the intended recipient. Thank you. >=20 _____________ 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. From owner-freebsd-arch@FreeBSD.ORG Mon Oct 8 00:31:02 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 631EB106566B; Mon, 8 Oct 2012 00:31:02 +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 24E878FC0A; Mon, 8 Oct 2012 00:31:01 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa05.fnfis.com (8.14.4/8.14.4) with ESMTP id q980V1p3014013 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 7 Oct 2012 19:31:01 -0500 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.15) with Microsoft SMTP Server (TLS) id 14.2.309.2; Sun, 7 Oct 2012 19:30:59 -0500 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Devin Teske In-Reply-To: <6DBE2255-40A3-452B-A503-04AF6A3FBE42@fisglobal.com> Date: Sun, 7 Oct 2012 17:30:58 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: References: <6DBE2255-40A3-452B-A503-04AF6A3FBE42@fisglobal.com> To: Garrett Cooper 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: Adrian Chadd , Devin Teske , freebsd-arch@freebsd.org Subject: Re: Tell the user we're booting 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: Mon, 08 Oct 2012 00:31:02 -0000 On Oct 7, 2012, at 4:10 PM, Devin Teske wrote: >=20 > On Oct 7, 2012, at 3:53 PM, Garrett Cooper wrote: >=20 >> On Oct 7, 2012, at 3:39 PM, Devin Teske wrote: >>=20 >>> Hi, >>>=20 >>> I'd like to propose a small (tiny even) patch to sys/boot/forth/loader.= 4th >>>=20 >>> Said patch will echo "Booting=85" before invoking the kernel. >>>=20 >>> This patch would effect every architecture (even those that don't use t= he beastie menu). >>>=20 >>> The reason for proposing this tiny change is that as of 9.0-R I've noti= ced a significant lag between executing "boot" and getting something on-scr= een to show that something is happening. >>=20 >> This is probably the memory test (set "hw.memtest.tests" to "0" in load= er.conf and see if that speeds things up). woah-nelly! I don't think I can count "one" before I see stuff show up on-s= creen. That's surely-it. >> Regardless, I think it'd be a good thing to have. Excellent, I'll move forward with the tiny patch. Thanks. Glad to improve t= he responsiveness (even if-only perceived). --=20 Devin P.S. You'll notice in the patch a ``strange'' ANSI color (37;44) when loade= r_color=3DYES, that's white-text on blue-background. That's a color that we= 've been using for nearly a decade and it seems to work quite well. I think= I read somewhere that blue is very soothing and calming (and that Disney k= nows this very well -- and is why they use a specific percentage of blue in= their movie previews). But hey, =85 we *could* change it (/me runs to comm= it ^_^) >> Thanks! >> -Garrett >>=20 >> PS Got patch? >=20 > Here's patch: >=20 > _____________ > The information contained in this message is proprietary and/or confident= ial. 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 awa= re that any message addressed to our domain is subject to archiving and rev= iew by persons other than the intended recipient. Thank you. > _____________ 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. From owner-freebsd-arch@FreeBSD.ORG Mon Oct 8 02:44:53 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 ABD2E106564A for ; Mon, 8 Oct 2012 02:44:53 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1BCE28FC0A for ; Mon, 8 Oct 2012 02:44:52 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so2290937lag.13 for ; Sun, 07 Oct 2012 19:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=frrhu70ZuE7tRhW1cpzA484cJuWt4fvLClIanD95gxo=; b=n1sZ2FoF4sMFjCzvFt6GGT6BTD+JmdoBqwgh3vNql1/U2gZIWdUFzqBKZg8fEKEk2B /KHWDjMne2T1tEMejeoKOPoS8XL9dPgCRTOGfyI1EIWv0CWLw2p3cgIFjGxq6k5EZM9e EehIbdzSUVszAXkSvBaKKvyyhRNbgJ8bsdgbU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=frrhu70ZuE7tRhW1cpzA484cJuWt4fvLClIanD95gxo=; b=QM5arQHv3lreUhI8yaCDHiRDnYREv/xSsSpdrZDXweIBBVUVyS10HvYFAWszpc2XQO tXXZ8yh7jWP/3RT0pXU1zluDwCv0DuTJLXFk1xUs2Y/7JYnThgL0u17rXhyqdfgfODd8 4sqHGaKiGX2jbXyWJ6+AY1QyEPXpYWfO7UlAULT6m/rh5TN02TkHRfic0pQ0MaZ1wQZy dZjTFgkPPzeHtrCyBnY5ZGgnmad1fd3MagxXqrzUhWB004rv6aw3NJoggr8Hb1lGS0ej SigBcMHivuf4tlTGS7vZm6z2nww6Tzu89BWEawMlSBdupt9lD0ICB7ugtUWPhGzW7HTy hOyw== MIME-Version: 1.0 Received: by 10.112.23.40 with SMTP id j8mr6155250lbf.31.1349664291757; Sun, 07 Oct 2012 19:44:51 -0700 (PDT) Received: by 10.112.87.106 with HTTP; Sun, 7 Oct 2012 19:44:51 -0700 (PDT) In-Reply-To: References: <6DBE2255-40A3-452B-A503-04AF6A3FBE42@fisglobal.com> Date: Sun, 7 Oct 2012 19:44:51 -0700 Message-ID: From: Peter Wemm To: Devin Teske Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmNotH0tTx3lRE2Z8X3uMs7dLUbh6vF8LGpXa25Kc2w0I5IeKNYhr1U7QFSfSW7RifRGrce Cc: Garrett Cooper , Adrian Chadd , freebsd-arch@freebsd.org Subject: Re: Tell the user we're booting 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: Mon, 08 Oct 2012 02:44:53 -0000 On Sun, Oct 7, 2012 at 5:30 PM, Devin Teske wro= te: > > On Oct 7, 2012, at 4:10 PM, Devin Teske wrote: > >> >> On Oct 7, 2012, at 3:53 PM, Garrett Cooper wrote: >> >>> On Oct 7, 2012, at 3:39 PM, Devin Teske wrote: >>> >>>> Hi, >>>> >>>> I'd like to propose a small (tiny even) patch to sys/boot/forth/loader= .4th >>>> >>>> Said patch will echo "Booting=85" before invoking the kernel. >>>> >>>> This patch would effect every architecture (even those that don't use = the beastie menu). >>>> >>>> The reason for proposing this tiny change is that as of 9.0-R I've not= iced a significant lag between executing "boot" and getting something on-sc= reen to show that something is happening. >>> >>> This is probably the memory test (set "hw.memtest.tests" to "0" in= loader.conf and see if that speeds things up). > > woah-nelly! I don't think I can count "one" before I see stuff show up on= -screen. That's surely-it. > > >>> Regardless, I think it'd be a good thing to have. > > Excellent, I'll move forward with the tiny patch. Thanks. Glad to improve= the responsiveness (even if-only perceived). > -- > Devin > > P.S. You'll notice in the patch a ``strange'' ANSI color (37;44) when loa= der_color=3DYES, that's white-text on blue-background. That's a color that = we've been using for nearly a decade and it seems to work quite well. I thi= nk I read somewhere that blue is very soothing and calming (and that Disney= knows this very well -- and is why they use a specific percentage of blue = in their movie previews). But hey, =85 we *could* change it (/me runs to co= mmit ^_^) If DDB/KDB is present and enabled you get a KDB printf before the memory check delay. The kernel clearly can afford to do an "I'm here!" message a little sooner than it currently does. At times I wonder if we could add something early, like: /* Test if the console is working yet. */ printf(" \\|/ ____ \\|/\n \"@'/ .. \\`@\"\n /_| \\__/ |_\\\n \\__U_/\n"); --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-arch@FreeBSD.ORG Mon Oct 8 03:08:45 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 07890106564A for ; Mon, 8 Oct 2012 03:08:45 +0000 (UTC) (envelope-from phlistbounces-thomas@phplist.com) Received: from mx39.phplist.com (mx39.phplist.com [50.23.48.196]) by mx1.freebsd.org (Postfix) with ESMTP id 9DE7D8FC08 for ; Mon, 8 Oct 2012 03:08:44 +0000 (UTC) Received: from mx39.phplist.com (mx39.phplist.com [50.23.48.196]) by mx39.phplist.com (Postfix) with ESMTP id 4E5F38688 for ; Mon, 8 Oct 2012 04:08:38 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=phplist.com; h=date:to :from:reply-to:subject:message-id:list-help:list-unsubscribe :list-subscribe:list-owner:mime-version:content-type; s=s0; bh=a 6O9nlUUb0Iq0t9J846TCTjWgGw=; b=KzOVRfIHv6pCfg9XvELqTBJFxgNxy/Igq OcUeSuptHnkaN687hZ1Nn1maBuX56HaCku2BuGTW2OqVwC8iA+C915c1BYDuSIW5 3kgTRqociiQ3J66WyrIqdnU6QcMwQ8SeWut3wNiCcZP8BQD/BMoyEruUU3B1CBkd uq+aZm9/Ic= Received: from thomas.hosted.phplist.com (mx39.phplist.com [50.23.48.196]) by mx39.phplist.com (Postfix) with ESMTP id 43FA58699 for ; Mon, 8 Oct 2012 04:08:38 +0100 (BST) Date: Mon, 8 Oct 2012 03:08:38 +0000 To: freebsd-arch@freebsd.org From: Thomas Sabo Message-ID: <78028e825131713e5d91de72163c8df1@localhost.localdomain> X-Priority: 3 X-Mailer: PHPMailer 5.1 (phpmailer.sourceforge.net) X-Mailer: phplist v2.11.6-hosted X-MessageID: 328 X-ListMember: freebsd-arch@freebsd.org Bounces-To: phlistbounces-thomas@phplist.com List-Owner: MIME-Version: 1.0 Content-Type: text/plain; charset = "UTF-8" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Only 3 Days - Thomas Sabo Up To 75% OFF Sale - Time Limit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Thomas Sabo List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 03:08:45 -0000 Can't see any images? - Click To View ! New Arrivals Best Sellers Pendants Charms Bracelets Necklaces Earrings Chains Carriers PLEASE NOTE: This email message was sent from a notification-only address that cannot accept incoming email. PLEASE DO NOT REPLY to this message. If you have any further questions please Contact Us . Thank you for reading this letter . http://thomas.hosted.phplist.com/lists/lt.php?id=N0UFAwUfAwZcH1VVUQEEBw%3D%3D -- powered by phpList, www.phplist.com -- From owner-freebsd-arch@FreeBSD.ORG Mon Oct 8 06:02:28 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 767DF106566B; Mon, 8 Oct 2012 06:02:28 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [69.147.83.54]) by mx2.freebsd.org (Postfix) with ESMTP id 26E4014EA84; Mon, 8 Oct 2012 06:02:28 +0000 (UTC) Message-ID: <50726C73.10506@FreeBSD.org> Date: Sun, 07 Oct 2012 23:02:27 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20121001 Thunderbird/15.0.1 MIME-Version: 1.0 To: Devin Teske References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <5071D6B5.1010609@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.4 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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 List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 06:02:28 -0000 On 10/07/2012 13:27, Devin Teske wrote: > > On Oct 7, 2012, at 12:23 PM, Doug Barton wrote: > > I reject your proposed hypothesis that this was my intent (the proper > intent is described below). > > >> "But that's not why I mentioned how many hours I spent." "So why >> mention it at all?" :) >> > > My precise intent for mentioning this was for the other Forth and/or > boot-menu folks (not the casual person). > > I didn't want the other Forth hackers to get excited and perhaps form > the markedly false impressions that either: > > b. that submenus were easy to add Right, you wanted us all to know how hard you worked. Congratulations, your efforts seem well received. >> 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? That works for me. > Because, as > previously discussed, if the menu stays as-is, we can really only > have one more item You keep saying that your current code allows for 9. There are 7 currently. Did I miss something? > 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). Given how few people will be using anything other than what is at the top level, I doubt it. However, given that we can have 9 more menu items on the second page of menus, why not have a few of the more popular items at the top, and then more submenus below? That's what is going to happen on the first menu page, so the UI will be consistent. >> 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? >> 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_? Um, if you don't already know the answers, I really can't help you. Go get a book on how to right proper user interfaces. Meanwhile, I've no objection to the idea of having move "safe mode" to a submenu, if that's the consensus. I don't think we should move ACPI because users who need to enable that option are already having enough problems as it is. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-arch@FreeBSD.ORG Mon Oct 8 10:08:00 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 B04CF106564A for ; Mon, 8 Oct 2012 10:08:00 +0000 (UTC) (envelope-from phlistbounces-thomas@phplist.com) Received: from mx33.phplist.com (mx33.phplist.com [50.23.59.116]) by mx1.freebsd.org (Postfix) with ESMTP id 842C58FC0A for ; Mon, 8 Oct 2012 10:08:00 +0000 (UTC) Received: from mx33.phplist.com (mx33.phplist.com [50.23.59.116]) by mx33.phplist.com (Postfix) with ESMTP id 9DF618078 for ; Mon, 8 Oct 2012 11:01:10 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=phplist.com; h=date:to :from:reply-to:subject:message-id:mime-version:content-type :content-transfer-encoding; s=s0; bh=35Eu1lAvSqkpry01KzNE1nWmQ5Y =; b=dfH6LRji/fGwG70QGiCh3XKwR1Luzh7Njl6dKCIIcy8GK/+K4ila9W/wj1Q paqJYD0OnwMs24Ejx4CIwUD29nGJec2Y2JPa4/US+EA0I/HXJNVN2FWeMlXo5K1A 57q13wDoiymiQfohcqNAl89MhVGazW54H8hLusrGlDMXp7I0= Received: from thomas.hosted.phplist.com (olive2 [50.23.51.195]) by mx33.phplist.com (Postfix) with ESMTP id 922798074 for ; Mon, 8 Oct 2012 11:01:10 +0100 (BST) Received: from crawl-66-249-74-172.googlebot.com [66.249.74.172] by thomas.hosted.phplist.com with HTTP; Mon, 08 Oct 2012 10:01:10 +0000 Date: Mon, 8 Oct 2012 10:01:10 +0000 To: freebsd-arch@freebsd.org From: Silverjewelryworld Message-ID: X-Priority: 3 X-Mailer: PHPMailer 5.1 (phpmailer.sourceforge.net) X-Mailer: phplist v2.11.6-hosted X-MessageID: systemmessage X-ListMember: freebsd-arch@freebsd.org Bounces-To: phlistbounces-thomas@phplist.com MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Goodbye from our Newsletter X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Silverjewelryworld List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 10:08:00 -0000 =20 Goodbye from our Newsletter, sorry to see you go. You have been unsubscribed from our newsletters. This is the last email you will receive from us. We have added you to o= ur "blacklist", which means that our newsletter system will refuse to send you any other email, without manual intervention by our administrator. If there is an error in this information, you can re-subscribe: please go to http://thomas.hosted.phplist.com/lists/?p=3Dsubscribe and follow the steps. Thank you =20 =20 From owner-freebsd-arch@FreeBSD.ORG Mon Oct 8 13:55:04 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 69DA0106566B for ; Mon, 8 Oct 2012 13:55:04 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1B7A48FC1A for ; Mon, 8 Oct 2012 13:55:04 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id k10so12230492iea.13 for ; Mon, 08 Oct 2012 06:55:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=b6Tq3EV15qs4P0ilQdGNUd5N7yLnT8cWFvBH7a6CCh8=; b=AZNsSY50ncXn4IYJqACYQ1SK2xq13IBAuogsAq5GMCkRYTUlbGHztJ40wc2vPFRtvq PaPIt3Zg7yAn//yt8QPLlhFAXrL3b90wu+Q7piAylBlJYoC0u8aUtJUj7hiv96DP5LO0 NNJBxNg68YRmfLRIAlt/eNnoq18B0xJT5X2EZRSblTXgacDc7sYNfe/zuNreDSl+c0zk CUNcoJ15erMyRHZWoJR5rf+zE714vKIET9nv5dvr4mMywMJ2C29iwYcVkh2OYhcEzghy HCSAFXXDyhJZ7/MhR2XVQxzZwSkbPbCvEcajXzuQRxOPepo0/uhDmpzCs4J4Z46f8spj ROIA== Received: by 10.50.207.36 with SMTP id lt4mr5957578igc.66.1349704502168; Mon, 08 Oct 2012 06:55:02 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id ex1sm6880136igc.4.2012.10.08.06.54.59 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Oct 2012 06:55:00 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <50726C73.10506@FreeBSD.org> Date: Mon, 8 Oct 2012 07:54:58 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8E009EA2-2274-4B46-8309-410EE8879C08@bsdimp.com> References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <5071D6B5.1010609@FreeBSD.org> <50726C73.10506@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQlO6nxsmLRENtEbyDlEDjNwOnkwiUSh1BDpaIhKsGPyQRRVpcj/VIpr8ahZQQGz+aPsmcNg Cc: "freebsd-arch@freebsd.org Arch" 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: Mon, 08 Oct 2012 13:55:04 -0000 On Oct 8, 2012, at 12:02 AM, Doug Barton wrote: >>> Regarding the UI on your submenu example; never, ever, ever use=20 >>> Backspace to mean anything other than "delete the character behind >>> the cursor." >>=20 >> Seriously? Who made _that_ rule? and moreover, _WHY_? >=20 > Um, if you don't already know the answers, I really can't help you. Go > get a book on how to right proper user interfaces. I've seen several interfaces that used this paradigm, and it works well = so long as BackSpace doesn't have another binding in that context. I'd = be curious to find a book that says NEVER, EVER do this. It drives me = nuts on my DVD player that I have to hit 'STOP' sometimes to get back to = the main menu, 'RETURN' other times, the back arrow other times and the = back rewind still other times depending on which context I'm in. They = are all the same bloody thing, and on other DVD players, they all do the = same thing, even if the back arrow is the only one they document (well, = except maybe for STOP, that's the odd-man out, but that part of the UI = of my DVD player is the part that sucks the most). So as primary and only, I'm not so sure. As an alias, it is fine. What = else are you going to do with it? A case could be made that you are = 'deleting' the previous character that got you to that menu. In the = absence of menu buttons that you can click on, there needs to be some = easy way to go back. > Meanwhile, I've no objection to the idea of having move "safe mode" to = a > submenu, if that's the consensus. I don't think we should move ACPI > because users who need to enable that option are already having enough > problems as it is. Maybe we need a menu item: "Help With Booting (special settings and = modes)" or something similar that we hide these things behind. While = "Advanced" might look sleek and cool, people unfamiliar with the boot = process won't think to try it if they are having trouble. Warner From owner-freebsd-arch@FreeBSD.ORG Mon Oct 8 15:48:55 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 C82B3106566B for ; Mon, 8 Oct 2012 15:48:55 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 705D18FC14 for ; Mon, 8 Oct 2012 15:48:54 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id q98FmrWq033779; Mon, 8 Oct 2012 10:48:53 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id q98Fmr9K033778; Mon, 8 Oct 2012 10:48:53 -0500 (CDT) (envelope-from brooks) Date: Mon, 8 Oct 2012 10:48:53 -0500 From: Brooks Davis To: Simon Gerraty Message-ID: <20121008154853.GC23400@lor.one-eyed-alien.net> References: <20121007001423.9878F58094@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TiqCXmo5T1hvSQQg" Content-Disposition: inline In-Reply-To: <20121007001423.9878F58094@chaos.jnpr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@freebsd.org Subject: Re: bsd.own.mk - just let WITHOUT_* take precedence 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: Mon, 08 Oct 2012 15:48:56 -0000 --TiqCXmo5T1hvSQQg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 06, 2012 at 05:14:23PM -0700, Simon Gerraty wrote: > After being bitten by: >=20 > make: "/b/sjg/work/fbsd-head/src/share/mk/bsd.own.mk" line 490: WITH_CTF > and WITHOUT_CTF can't both be set. >=20 > I took a look at bsd.own.mk > I'm not sure what's so evil about setting both WITH_ and WITHOUT_ > especially when bits of buildworld, buildkernel etc, set WITHOUT_ > (which triggers the problem for me). >=20 > All that seems necessary is a clear rule - "WITHOUT_ wins". > Thus the patch below solve my problem. I'm not sure if I agree or not, I'll have to think more. This sort of thing that leads to me yelling at my computer "but I @#%$@# set WITH_FOO you ^@$@! machine." :) I think we should at a minimum issue a warning and say what we did. It won't help a lot if the output is lost when running "make -j16 -DWITH_FOO buildworld", but at least we'll have told the user that their make.conf or src.conf setting was why the feature they turned on didn't work. The implementation looks mostly fine. I do think it skips some options with variable defaults (LIBCXX in HEAD for example) so I think you'd need to sprinkle more of these changes in. -- Brooks >=20 > Index: share/mk/bsd.own.mk > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- share/mk/bsd.own.mk (revision 241871) > +++ share/mk/bsd.own.mk (working copy) > @@ -468,9 +468,6 @@ __DEFAULT_NO_OPTIONS+=3DFDT > # MK_* options which default to "yes". > # > .for var in ${__DEFAULT_YES_OPTIONS} > -.if defined(WITH_${var}) && defined(WITHOUT_${var}) > -.error WITH_${var} and WITHOUT_${var} can't both be set. > -.endif > .if defined(MK_${var}) > .error MK_${var} can't be set by a user. > .endif > @@ -486,13 +483,10 @@ MK_${var}:=3D yes > # MK_* options which default to "no". > # > .for var in ${__DEFAULT_NO_OPTIONS} > -.if defined(WITH_${var}) && defined(WITHOUT_${var}) > -.error WITH_${var} and WITHOUT_${var} can't both be set. > -.endif > .if defined(MK_${var}) > .error MK_${var} can't be set by a user. > .endif > -.if defined(WITH_${var}) > +.if defined(WITH_${var}) && !defined(WITHOUT_${var}) > MK_${var}:=3D yes > .else > MK_${var}:=3D no > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >=20 --TiqCXmo5T1hvSQQg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFQcvXlXY6L6fI4GtQRAsRDAJsF2/I+qR4kRKEaNBnR/CGTxobrUQCg5ejk zBv6UkxkyG+7kWrV0hT1wao= =jGO3 -----END PGP SIGNATURE----- --TiqCXmo5T1hvSQQg-- From owner-freebsd-arch@FreeBSD.ORG Mon Oct 8 16:11:35 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 A6E96106566B; Mon, 8 Oct 2012 16:11:35 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 5DFBB8FC0A; Mon, 8 Oct 2012 16:11:35 +0000 (UTC) Received: from sa-nc-cs-116.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q98GBW7O082253 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 8 Oct 2012 09:11:33 -0700 (PDT) (envelope-from marcel@xcllnt.net) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Marcel Moolenaar In-Reply-To: Date: Mon, 8 Oct 2012 09:11:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <127FA63D-8EEE-4616-AE1E-C39469DDCC6A@xcllnt.net> References: <201210020750.23358.jhb@freebsd.org> <201210021037.27762.jhb@freebsd.org> To: Garrett Cooper X-Mailer: Apple Mail (2.1499) Cc: freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org, "Simon J. Gerraty" Subject: Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program 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: Mon, 08 Oct 2012 16:11:35 -0000 On Oct 4, 2012, at 9:42 AM, Garrett Cooper wrote: >>> Both parties (Isilon/Juniper) are converging on the ATF porting work >>> that Giorgos/myself have done after talking at the FreeBSD = Foundation >>> meet-n-greet. I have contributed all of the patches that I have = other >>> to marcel for feedback. >>=20 >> This is very non-obvious to the public at large (e.g. there was no = public >> response to one group's inquiry about the second ATF import for = example). >> Also, given that you had no idea that sgf@ and obrien@ were working = on >> importing NetBSD's bmake as a prerequisite for ATF, it seems that = whatever >> discussions were held were not very detailed at best. I think it = would be >> good to have the various folks working on ATF to at least summarize = the >> current state of things and sketch out some sort of plan or roadmap = for future >> work in a public forum (such as atf@, though a summary mail would be = quite >> appropriate for arch@). >=20 > I'm in part to blame for this. There was some discussion -- but not at > length; unfortunately no one from Juniper was present at the meet and > greet; the information I got was second hand; I didn't follow up to > figure out the exact details / clarify what I had in mind with the > appropriate parties. Hang on. I want in on the blame part! :-) Seriously: no-one is really to blame as far as I can see. We just had two independent efforts (ATF & bmake) and there was no indication that one would be greatly benefitted from the other. At least not to the point of creating a dependency. I just committed the bmake bits. It not only adds bmake to the build, but also includes the changes necessary to use bmake. With that in place it's easier to decide whether we want the dependency or not. Before we can switch permanently to bmake, we need to do the following first: 1. Request an EXP ports build with bmake as make(1). This should tell us the "damage" of switching to bmake for ports. 2. In parallel with 1: build www & docs with bmake and assess the damage 3. Fix all the damage Then: 4. Switch. It could be a while (many weeks) before we get to 4, so the question really is whether the people working on ATF are willing and able to build and install FreeBSD using WITH_BMAKE? --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Mon Oct 8 16:52:48 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 134EA1065672 for ; Mon, 8 Oct 2012 16:52:48 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 149D88FC1C for ; Mon, 8 Oct 2012 16:52:32 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id q98GqUth034187 for ; Mon, 8 Oct 2012 11:52:30 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id q98GqUCg034186 for freebsd-arch@freebsd.org; Mon, 8 Oct 2012 11:52:30 -0500 (CDT) (envelope-from brooks) Date: Mon, 8 Oct 2012 11:52:30 -0500 From: Brooks Davis To: freebsd-arch@freebsd.org Message-ID: <20121008165230.GD23400@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SFyWQ0h3ruR435lw" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [CFT] Importing NetBSD's pwcache(3) 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: Mon, 08 Oct 2012 16:52:48 -0000 --SFyWQ0h3ruR435lw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm planning to import NetBSD's implementation and expansion of pwcache(3). The main feature is that it adds is the new functions gid_from_group(), pwcache_userdb(), pwcache_groupdb(), and uid_from_user(). The *_from_*() functions do what you'd expect. The pwcache*() functions allow you to implement alternative lookup functions. NetBSD's mtree and install use them to support alternate master.passwd and group files. They use it to support image creation on non-NetBSD systems. In principle this could eliminate the need to run mergemaster before installworld after a new user or group is added to the system (assuming of course that the admin isn't randomly renumbering users and groups). If you wish to test this patch, apply it and then delete lib/libc/gen/pwcache.[3c] so the new versions in contrib are found. The actual commit will include a copy from vendor/NetBSD/libc-pwcache/dist to contrib/libc-pwcache. Thanks, Brooks Index: lib/libc/gen/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- lib/libc/gen/Makefile.inc (revision 241235) +++ lib/libc/gen/Makefile.inc (working copy) @@ -24,7 +24,7 @@ lockf.c lrand48.c mrand48.c nftw.c nice.c \ nlist.c nrand48.c opendir.c \ pause.c pmadvise.c popen.c posix_spawn.c \ - psignal.c pututxline.c pw_scan.c pwcache.c \ + psignal.c pututxline.c pw_scan.c \ raise.c readdir.c readpassphrase.c rewinddir.c \ scandir.c seed48.c seekdir.c semctl.c \ setdomainname.c sethostname.c setjmperr.c setmode.c \ @@ -36,6 +36,9 @@ usleep.c utime.c utxdb.c valloc.c vis.c wait.c wait3.c waitpid.c \ wordexp.c =20 +.PATH: ${.CURDIR}/../../contrib/libc-pwcache +SRCS+=3D pwcache.c pwcache.h + MISRCS+=3Dmodf.c =20 CANCELPOINTS_SRCS=3Dsem.c sem_new.c Index: lib/libc/gen/pwcache.3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- lib/libc/gen/pwcache.3 (revision 241235) +++ lib/libc/gen/pwcache.3 (working copy) @@ -1,93 +0,0 @@ -.\" Copyright (c) 1989, 1991, 1993 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 4. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this softwa= re -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PUR= POSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIAB= LE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUEN= TIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, ST= RICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY = WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" -.\" @(#)pwcache.3 8.1 (Berkeley) 6/9/93 -.\" $FreeBSD$ -.\" -.Dd March 22, 2002 -.Dt PWCACHE 3 -.Os -.Sh NAME -.Nm pwcache -.Nd cache password and group entries -.Sh LIBRARY -.Lb libc -.Sh SYNOPSIS -.In pwd.h -.Ft const char * -.Fn user_from_uid "uid_t uid" "int nouser" -.In grp.h -.Ft const char * -.Fn group_from_gid "gid_t gid" "int nogroup" -.Sh DESCRIPTION -The -.Fn user_from_uid -function returns the user name associated with the argument -.Fa uid . -The user name is cached so that multiple calls with the same -.Fa uid -do not require additional calls to -.Xr getpwuid 3 . -If there is no user associated with the -.Fa uid , -a pointer is returned -to a string representation of the -.Fa uid , -unless the argument -.Fa nouser -is non-zero, in which case a -.Dv NULL -pointer is returned. -.Pp -The -.Fn group_from_gid -function returns the group name associated with the argument -.Fa gid . -The group name is cached so that multiple calls with the same -.Fa gid -do not require additional calls to -.Xr getgrgid 3 . -If there is no group associated with the -.Fa gid , -a pointer is returned -to a string representation of the -.Fa gid , -unless the argument -.Fa nogroup -is non-zero, in which case a -.Dv NULL -pointer is returned. -.Sh SEE ALSO -.Xr getgrgid 3 , -.Xr getpwuid 3 -.Sh HISTORY -The -.Fn user_from_uid -and -.Fn group_from_gid -functions first appeared in -.Bx 4.4 . Index: lib/libc/gen/pwcache.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- lib/libc/gen/pwcache.c (revision 241235) +++ lib/libc/gen/pwcache.c (working copy) @@ -1,113 +0,0 @@ -/* - * Copyright (c) 1989, 1993 - * The Regents of the University of California. All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * 1. Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * 2. Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in the - * documentation and/or other materials provided with the distribution. - * 4. Neither the name of the University nor the names of its contributors - * may be used to endorse or promote products derived from this software - * without specific prior written permission. - * - * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND - * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE - * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURP= OSE - * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE - * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENT= IAL - * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS - * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) - * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STR= ICT - * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY W= AY - * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF - * SUCH DAMAGE. - */ - -#if defined(LIBC_SCCS) && !defined(lint) -static char sccsid[] =3D "@(#)pwcache.c 8.1 (Berkeley) 6/4/93"; -#endif /* LIBC_SCCS and not lint */ -#include -__FBSDID("$FreeBSD$"); - -#include -#include - -#include -#include -#include -#include - -#define NCACHE 64 /* power of 2 */ -#define MASK (NCACHE - 1) /* bits to store with */ - -const char * -user_from_uid(uid_t uid, int nouser) -{ - static struct ncache { - uid_t uid; - int found; - char name[MAXLOGNAME]; - } c_uid[NCACHE]; - static int pwopen; - struct passwd *pw; - struct ncache *cp; - - cp =3D c_uid + (uid & MASK); - if (cp->uid !=3D uid || !*cp->name) { - if (pwopen =3D=3D 0) { - setpassent(1); - pwopen =3D 1; - } - pw =3D getpwuid(uid); - cp->uid =3D uid; - if (pw !=3D NULL) { - cp->found =3D 1; - (void)strncpy(cp->name, pw->pw_name, MAXLOGNAME - 1); - cp->name[MAXLOGNAME - 1] =3D '\0'; - } else { - cp->found =3D 0; - (void)snprintf(cp->name, MAXLOGNAME - 1, "%u", uid); - if (nouser) - return (NULL); - } - } - return ((nouser && !cp->found) ? NULL : cp->name); -} - -const char * -group_from_gid(gid_t gid, int nogroup) -{ - static struct ncache { - gid_t gid; - int found; - char name[MAXLOGNAME]; - } c_gid[NCACHE]; - static int gropen; - struct group *gr; - struct ncache *cp; - - cp =3D c_gid + (gid & MASK); - if (cp->gid !=3D gid || !*cp->name) { - if (gropen =3D=3D 0) { - setgroupent(1); - gropen =3D 1; - } - gr =3D getgrgid(gid); - cp->gid =3D gid; - if (gr !=3D NULL) { - cp->found =3D 1; - (void)strncpy(cp->name, gr->gr_name, MAXLOGNAME - 1); - cp->name[MAXLOGNAME - 1] =3D '\0'; - } else { - cp->found =3D 0; - (void)snprintf(cp->name, MAXLOGNAME - 1, "%u", gid); - if (nogroup) - return (NULL); - } - } - return ((nogroup && !cp->found) ? NULL : cp->name); -} Index: lib/libc/gen/Symbol.map =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- lib/libc/gen/Symbol.map (revision 241235) +++ lib/libc/gen/Symbol.map (working copy) @@ -387,6 +387,10 @@ fdlopen; __FreeBSD_libc_enter_restricted_mode; getcontextx; + gid_from_group; + pwcache_userdb; + pwcache_groupdb; + uid_from_user; }; =20 FBSDprivate_1.0 { Index: include/pwd.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- include/pwd.h (revision 241235) +++ include/pwd.h (working copy) @@ -165,6 +165,10 @@ int getpwent_r(struct passwd *, char *, size_t, struct passwd **); int setpassent(int); const char *user_from_uid(uid_t, int); +int uid_from_user(const char *, uid_t *); +int pwcache_userdb(int (*)(int), void (*)(void), + struct passwd * (*)(const char *), + struct passwd * (*)(uid_t)); #endif __END_DECLS =20 Index: include/grp.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- include/grp.h (revision 241235) +++ include/grp.h (working copy) @@ -69,6 +69,10 @@ struct group *getgrnam(const char *); #if __BSD_VISIBLE const char *group_from_gid(gid_t, int); +int gid_from_group(const char *, gid_t *); +int pwcache_groupdb(int (*)(int), void (*)(void), + struct group * (*)(const char *), + struct group * (*)(gid_t)); #endif #if __BSD_VISIBLE || __XSI_VISIBLE /* XXX IEEE Std 1003.1, 2003 specifies `void setgrent(void)' */ Index: contrib/libc-pwcache/pwcache.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- contrib/libc-pwcache/pwcache.h (revision 0) +++ contrib/libc-pwcache/pwcache.h (working copy) @@ -0,0 +1,73 @@ +/* $NetBSD: pwcache.h,v 1.5 2003/11/10 08:51:51 wiz Exp $ */ +/* $FreeBSD$ */ + +/*- + * Copyright (c) 1992 Keith Muller. + * Copyright (c) 1992, 1993 + * The Regents of the University of California. All rights reserved. + * + * This code is derived from software contributed to Berkeley by + * Keith Muller of the University of California, San Diego. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURP= OSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENT= IAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STR= ICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY W= AY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * @(#)cache.h 8.1 (Berkeley) 5/31/93 + */ + +/* + * Constants and data structures used to implement group and password file + * caches. Traditional passwd/group cache routines perform quite poorly wi= th + * archives. The chances of hitting a valid lookup with an archive is quit= e a + * bit worse than with files already resident on the file system. These mi= sses + * create a MAJOR performance cost. To address this problem, these routines + * cache both hits and misses. + * + * NOTE: name lengths must be as large as those stored in ANY PROTOCOL and + * as stored in the passwd and group files. CACHE SIZES MUST BE PRIME + */ +#define UNMLEN 32 /* >=3D user name found in any protocol */ +#define GNMLEN 32 /* >=3D group name found in any protocol */ +#define UID_SZ 317 /* size of uid to user_name cache */ +#define UNM_SZ 317 /* size of user_name to uid cache */ +#define GID_SZ 251 /* size of gid to group_name cache */ +#define GNM_SZ 251 /* size of group_name to gid cache */ +#define VALID 1 /* entry and name are valid */ +#define INVALID 2 /* entry valid, name NOT valid */ + +/* + * Node structures used in the user, group, uid, and gid caches. + */ + +typedef struct uidc { + int valid; /* is this a valid or a miss entry */ + char name[UNMLEN]; /* uid name */ + uid_t uid; /* cached uid */ +} UIDC; + +typedef struct gidc { + int valid; /* is this a valid or a miss entry */ + char name[GNMLEN]; /* gid name */ + gid_t gid; /* cached gid */ +} GIDC; Property changes on: contrib/libc-pwcache/pwcache.h ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Index: contrib/libc-pwcache/pwcache.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- contrib/libc-pwcache/pwcache.c (revision 0) +++ contrib/libc-pwcache/pwcache.c (working copy) @@ -0,0 +1,646 @@ +/* $NetBSD: pwcache.c,v 1.31 2010/03/23 20:28:59 drochner Exp $ */ + +/*- + * Copyright (c) 1992 Keith Muller. + * Copyright (c) 1992, 1993 + * The Regents of the University of California. All rights reserved. + * + * This code is derived from software contributed to Berkeley by + * Keith Muller of the University of California, San Diego. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURP= OSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENT= IAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STR= ICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY W= AY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +/*- + * Copyright (c) 2002 The NetBSD Foundation, Inc. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTO= RS + * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIM= ITED + * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICU= LAR + * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTO= RS + * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF = THE + * POSSIBILITY OF SUCH DAMAGE. + */ + +#if HAVE_NBTOOL_CONFIG_H +#include "nbtool_config.h" +/* + * XXX Undefine the renames of these functions so that we don't + * XXX rename the versions found in the host's by mistake! + */ +#undef group_from_gid +#undef user_from_uid +#endif + +#include +#if defined(LIBC_SCCS) && !defined(lint) +#if 0 +static char sccsid[] =3D "@(#)cache.c 8.1 (Berkeley) 5/31/93"; +#else +__RCSID("$NetBSD: pwcache.c,v 1.31 2010/03/23 20:28:59 drochner Exp $"); +#endif +#endif /* LIBC_SCCS and not lint */ +__FBSDID("$FreeBSD$"); + +#include "namespace.h" + +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +#define _DIAGASSERT(x) assert((x)) + +#if HAVE_NBTOOL_CONFIG_H +/* XXX Now, re-apply the renaming that we undid above. */ +#define group_from_gid __nbcompat_group_from_gid +#define user_from_uid __nbcompat_user_from_uid +#endif + +#ifdef __weak_alias +__weak_alias(user_from_uid,_user_from_uid) +__weak_alias(group_from_gid,_group_from_gid) +__weak_alias(pwcache_groupdb,_pwcache_groupdb) +#endif + +#if !HAVE_PWCACHE_USERDB || HAVE_NBTOOL_CONFIG_H +#include "pwcache.h" + +/* + * routines that control user, group, uid and gid caches (for the archive + * member print routine). + * IMPORTANT: + * these routines cache BOTH hits and misses, a major performance improvem= ent + */ + +/* + * function pointers to various name lookup routines. + * these may be changed as necessary. + */ +static int (*_pwcache_setgroupent)(int) =3D setgroupent; +static void (*_pwcache_endgrent)(void) =3D endgrent; +static struct group * (*_pwcache_getgrnam)(const char *) =3D getgrnam; +static struct group * (*_pwcache_getgrgid)(gid_t) =3D getgrgid; +static int (*_pwcache_setpassent)(int) =3D setpassent; +static void (*_pwcache_endpwent)(void) =3D endpwent; +static struct passwd * (*_pwcache_getpwnam)(const char *) =3D getpwnam; +static struct passwd * (*_pwcache_getpwuid)(uid_t) =3D getpwuid; + +/* + * internal state + */ +static int pwopn; /* is password file open */ +static int gropn; /* is group file open */ +static UIDC **uidtb; /* uid to name cache */ +static GIDC **gidtb; /* gid to name cache */ +static UIDC **usrtb; /* user name to uid cache */ +static GIDC **grptb; /* group name to gid cache */ + +static int uidtb_fail; /* uidtb_start() failed ? */ +static int gidtb_fail; /* gidtb_start() failed ? */ +static int usrtb_fail; /* usrtb_start() failed ? */ +static int grptb_fail; /* grptb_start() failed ? */ + + +static u_int st_hash(const char *, size_t, int); +static int uidtb_start(void); +static int gidtb_start(void); +static int usrtb_start(void); +static int grptb_start(void); + + +static u_int +st_hash(const char *name, size_t len, int tabsz) +{ + u_int key =3D 0; + + _DIAGASSERT(name !=3D NULL); + + while (len--) { + key +=3D *name++; + key =3D (key << 8) | (key >> 24); + } + + return (key % tabsz); +} + +/* + * uidtb_start + * creates an an empty uidtb + * Return: + * 0 if ok, -1 otherwise + */ +static int +uidtb_start(void) +{ + + if (uidtb !=3D NULL) + return (0); + if (uidtb_fail) + return (-1); + if ((uidtb =3D (UIDC **)calloc(UID_SZ, sizeof(UIDC *))) =3D=3D NULL) { + ++uidtb_fail; + return (-1); + } + return (0); +} + +/* + * gidtb_start + * creates an an empty gidtb + * Return: + * 0 if ok, -1 otherwise + */ +static int +gidtb_start(void) +{ + + if (gidtb !=3D NULL) + return (0); + if (gidtb_fail) + return (-1); + if ((gidtb =3D (GIDC **)calloc(GID_SZ, sizeof(GIDC *))) =3D=3D NULL) { + ++gidtb_fail; + return (-1); + } + return (0); +} + +/* + * usrtb_start + * creates an an empty usrtb + * Return: + * 0 if ok, -1 otherwise + */ +static int +usrtb_start(void) +{ + + if (usrtb !=3D NULL) + return (0); + if (usrtb_fail) + return (-1); + if ((usrtb =3D (UIDC **)calloc(UNM_SZ, sizeof(UIDC *))) =3D=3D NULL) { + ++usrtb_fail; + return (-1); + } + return (0); +} + +/* + * grptb_start + * creates an an empty grptb + * Return: + * 0 if ok, -1 otherwise + */ +static int +grptb_start(void) +{ + + if (grptb !=3D NULL) + return (0); + if (grptb_fail) + return (-1); + if ((grptb =3D (GIDC **)calloc(GNM_SZ, sizeof(GIDC *))) =3D=3D NULL) { + ++grptb_fail; + return (-1); + } + return (0); +} + +/* + * user_from_uid() + * caches the name (if any) for the uid. If noname clear, we always + * return the stored name (if valid or invalid match). + * We use a simple hash table. + * Return + * Pointer to stored name (or a empty string) + */ +const char * +user_from_uid(uid_t uid, int noname) +{ + struct passwd *pw; + UIDC *ptr, **pptr; + + if ((uidtb =3D=3D NULL) && (uidtb_start() < 0)) + return (NULL); + + /* + * see if we have this uid cached + */ + pptr =3D uidtb + (uid % UID_SZ); + ptr =3D *pptr; + + if ((ptr !=3D NULL) && (ptr->valid > 0) && (ptr->uid =3D=3D uid)) { + /* + * have an entry for this uid + */ + if (!noname || (ptr->valid =3D=3D VALID)) + return (ptr->name); + return (NULL); + } + + /* + * No entry for this uid, we will add it + */ + if (!pwopn) { + if (_pwcache_setpassent !=3D NULL) + (*_pwcache_setpassent)(1); + ++pwopn; + } + + if (ptr =3D=3D NULL) + *pptr =3D ptr =3D (UIDC *)malloc(sizeof(UIDC)); + + if ((pw =3D (*_pwcache_getpwuid)(uid)) =3D=3D NULL) { + /* + * no match for this uid in the local password file + * a string that is the uid in numeric format + */ + if (ptr =3D=3D NULL) + return (NULL); + ptr->uid =3D uid; + (void)snprintf(ptr->name, UNMLEN, "%lu", (long) uid); + ptr->valid =3D INVALID; + if (noname) + return (NULL); + } else { + /* + * there is an entry for this uid in the password file + */ + if (ptr =3D=3D NULL) + return (pw->pw_name); + ptr->uid =3D uid; + (void)strlcpy(ptr->name, pw->pw_name, UNMLEN); + ptr->valid =3D VALID; + } + return (ptr->name); +} + +/* + * group_from_gid() + * caches the name (if any) for the gid. If noname clear, we always + * return the stored name (if valid or invalid match). + * We use a simple hash table. + * Return + * Pointer to stored name (or a empty string) + */ +const char * +group_from_gid(gid_t gid, int noname) +{ + struct group *gr; + GIDC *ptr, **pptr; + + if ((gidtb =3D=3D NULL) && (gidtb_start() < 0)) + return (NULL); + + /* + * see if we have this gid cached + */ + pptr =3D gidtb + (gid % GID_SZ); + ptr =3D *pptr; + + if ((ptr !=3D NULL) && (ptr->valid > 0) && (ptr->gid =3D=3D gid)) { + /* + * have an entry for this gid + */ + if (!noname || (ptr->valid =3D=3D VALID)) + return (ptr->name); + return (NULL); + } + + /* + * No entry for this gid, we will add it + */ + if (!gropn) { + if (_pwcache_setgroupent !=3D NULL) + (*_pwcache_setgroupent)(1); + ++gropn; + } + + if (ptr =3D=3D NULL) + *pptr =3D ptr =3D (GIDC *)malloc(sizeof(GIDC)); + + if ((gr =3D (*_pwcache_getgrgid)(gid)) =3D=3D NULL) { + /* + * no match for this gid in the local group file, put in + * a string that is the gid in numberic format + */ + if (ptr =3D=3D NULL) + return (NULL); + ptr->gid =3D gid; + (void)snprintf(ptr->name, GNMLEN, "%lu", (long) gid); + ptr->valid =3D INVALID; + if (noname) + return (NULL); + } else { + /* + * there is an entry for this group in the group file + */ + if (ptr =3D=3D NULL) + return (gr->gr_name); + ptr->gid =3D gid; + (void)strlcpy(ptr->name, gr->gr_name, GNMLEN); + ptr->valid =3D VALID; + } + return (ptr->name); +} + +/* + * uid_from_user() + * caches the uid for a given user name. We use a simple hash table. + * Return + * the uid (if any) for a user name, or a -1 if no match can be found + */ +int +uid_from_user(const char *name, uid_t *uid) +{ + struct passwd *pw; + UIDC *ptr, **pptr; + size_t namelen; + + /* + * return -1 for mangled names + */ + if (name =3D=3D NULL || ((namelen =3D strlen(name)) =3D=3D 0)) + return (-1); + if ((usrtb =3D=3D NULL) && (usrtb_start() < 0)) + return (-1); + + /* + * look up in hash table, if found and valid return the uid, + * if found and invalid, return a -1 + */ + pptr =3D usrtb + st_hash(name, namelen, UNM_SZ); + ptr =3D *pptr; + + if ((ptr !=3D NULL) && (ptr->valid > 0) && !strcmp(name, ptr->name)) { + if (ptr->valid =3D=3D INVALID) + return (-1); + *uid =3D ptr->uid; + return (0); + } + + if (!pwopn) { + if (_pwcache_setpassent !=3D NULL) + (*_pwcache_setpassent)(1); + ++pwopn; + } + + if (ptr =3D=3D NULL) + *pptr =3D ptr =3D (UIDC *)malloc(sizeof(UIDC)); + + /* + * no match, look it up, if no match store it as an invalid entry, + * or store the matching uid + */ + if (ptr =3D=3D NULL) { + if ((pw =3D (*_pwcache_getpwnam)(name)) =3D=3D NULL) + return (-1); + *uid =3D pw->pw_uid; + return (0); + } + (void)strlcpy(ptr->name, name, UNMLEN); + if ((pw =3D (*_pwcache_getpwnam)(name)) =3D=3D NULL) { + ptr->valid =3D INVALID; + return (-1); + } + ptr->valid =3D VALID; + *uid =3D ptr->uid =3D pw->pw_uid; + return (0); +} + +/* + * gid_from_group() + * caches the gid for a given group name. We use a simple hash table. + * Return + * the gid (if any) for a group name, or a -1 if no match can be found + */ +int +gid_from_group(const char *name, gid_t *gid) +{ + struct group *gr; + GIDC *ptr, **pptr; + size_t namelen; + + /* + * return -1 for mangled names + */ + if (name =3D=3D NULL || ((namelen =3D strlen(name)) =3D=3D 0)) + return (-1); + if ((grptb =3D=3D NULL) && (grptb_start() < 0)) + return (-1); + + /* + * look up in hash table, if found and valid return the uid, + * if found and invalid, return a -1 + */ + pptr =3D grptb + st_hash(name, namelen, GID_SZ); + ptr =3D *pptr; + + if ((ptr !=3D NULL) && (ptr->valid > 0) && !strcmp(name, ptr->name)) { + if (ptr->valid =3D=3D INVALID) + return (-1); + *gid =3D ptr->gid; + return (0); + } + + if (!gropn) { + if (_pwcache_setgroupent !=3D NULL) + (*_pwcache_setgroupent)(1); + ++gropn; + } + + if (ptr =3D=3D NULL) + *pptr =3D ptr =3D (GIDC *)malloc(sizeof(GIDC)); + + /* + * no match, look it up, if no match store it as an invalid entry, + * or store the matching gid + */ + if (ptr =3D=3D NULL) { + if ((gr =3D (*_pwcache_getgrnam)(name)) =3D=3D NULL) + return (-1); + *gid =3D gr->gr_gid; + return (0); + } + + (void)strlcpy(ptr->name, name, GNMLEN); + if ((gr =3D (*_pwcache_getgrnam)(name)) =3D=3D NULL) { + ptr->valid =3D INVALID; + return (-1); + } + ptr->valid =3D VALID; + *gid =3D ptr->gid =3D gr->gr_gid; + return (0); +} + +#define FLUSHTB(arr, len, fail) \ + do { \ + if (arr !=3D NULL) { \ + for (i =3D 0; i < len; i++) \ + if (arr[i] !=3D NULL) \ + free(arr[i]); \ + arr =3D NULL; \ + } \ + fail =3D 0; \ + } while (/* CONSTCOND */0); + +int +pwcache_userdb( + int (*a_setpassent)(int), + void (*a_endpwent)(void), + struct passwd * (*a_getpwnam)(const char *), + struct passwd * (*a_getpwuid)(uid_t)) +{ + int i; + + /* a_setpassent and a_endpwent may be NULL */ + if (a_getpwnam =3D=3D NULL || a_getpwuid =3D=3D NULL) + return (-1); + + if (_pwcache_endpwent !=3D NULL) + (*_pwcache_endpwent)(); + FLUSHTB(uidtb, UID_SZ, uidtb_fail); + FLUSHTB(usrtb, UNM_SZ, usrtb_fail); + pwopn =3D 0; + _pwcache_setpassent =3D a_setpassent; + _pwcache_endpwent =3D a_endpwent; + _pwcache_getpwnam =3D a_getpwnam; + _pwcache_getpwuid =3D a_getpwuid; + + return (0); +} + +int +pwcache_groupdb( + int (*a_setgroupent)(int), + void (*a_endgrent)(void), + struct group * (*a_getgrnam)(const char *), + struct group * (*a_getgrgid)(gid_t)) +{ + int i; + + /* a_setgroupent and a_endgrent may be NULL */ + if (a_getgrnam =3D=3D NULL || a_getgrgid =3D=3D NULL) + return (-1); + + if (_pwcache_endgrent !=3D NULL) + (*_pwcache_endgrent)(); + FLUSHTB(gidtb, GID_SZ, gidtb_fail); + FLUSHTB(grptb, GNM_SZ, grptb_fail); + gropn =3D 0; + _pwcache_setgroupent =3D a_setgroupent; + _pwcache_endgrent =3D a_endgrent; + _pwcache_getgrnam =3D a_getgrnam; + _pwcache_getgrgid =3D a_getgrgid; + + return (0); +} + + +#ifdef TEST_PWCACHE + +struct passwd * +test_getpwnam(const char *name) +{ + static struct passwd foo; + + memset(&foo, 0, sizeof(foo)); + if (strcmp(name, "toor") =3D=3D 0) { + foo.pw_uid =3D 666; + return &foo; + } + return (getpwnam(name)); +} + +int +main(int argc, char *argv[]) +{ + uid_t u; + int r, i; + + printf("pass 1 (default userdb)\n"); + for (i =3D 1; i < argc; i++) { + printf("i: %d, pwopn %d usrtb_fail %d usrtb %p\n", + i, pwopn, usrtb_fail, usrtb); + r =3D uid_from_user(argv[i], &u); + if (r =3D=3D -1) + printf(" uid_from_user %s: failed\n", argv[i]); + else + printf(" uid_from_user %s: %d\n", argv[i], u); + } + printf("pass 1 finish: pwopn %d usrtb_fail %d usrtb %p\n", + pwopn, usrtb_fail, usrtb); + + puts(""); + printf("pass 2 (replacement userdb)\n"); + printf("pwcache_userdb returned %d\n", + pwcache_userdb(setpassent, test_getpwnam, getpwuid)); + printf("pwopn %d usrtb_fail %d usrtb %p\n", pwopn, usrtb_fail, usrtb); + + for (i =3D 1; i < argc; i++) { + printf("i: %d, pwopn %d usrtb_fail %d usrtb %p\n", + i, pwopn, usrtb_fail, usrtb); + u =3D -1; + r =3D uid_from_user(argv[i], &u); + if (r =3D=3D -1) + printf(" uid_from_user %s: failed\n", argv[i]); + else + printf(" uid_from_user %s: %d\n", argv[i], u); + } + printf("pass 2 finish: pwopn %d usrtb_fail %d usrtb %p\n", + pwopn, usrtb_fail, usrtb); + + puts(""); + printf("pass 3 (null pointers)\n"); + printf("pwcache_userdb returned %d\n", + pwcache_userdb(NULL, NULL, NULL)); + + return (0); +} +#endif /* TEST_PWCACHE */ +#endif /* !HAVE_PWCACHE_USERDB */ Property changes on: contrib/libc-pwcache/pwcache.c ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Index: contrib/libc-pwcache/pwcache.3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- contrib/libc-pwcache/pwcache.3 (revision 0) +++ contrib/libc-pwcache/pwcache.3 (working copy) @@ -0,0 +1,221 @@ +.\" $NetBSD: pwcache.3,v 1.17 2008/05/02 18:11:04 martin Exp $ +.\" $FreeBSD$ +.\" +.\" Copyright (c) 1989, 1991, 1993 +.\" The Regents of the University of California. All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" 3. Neither the name of the University nor the names of its contributors +.\" may be used to endorse or promote products derived from this softwa= re +.\" without specific prior written permission. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PUR= POSE +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIAB= LE +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUEN= TIAL +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, ST= RICT +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY = WAY +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\" SUCH DAMAGE. +.\" +.\" +.\" Copyright (c) 2002 The NetBSD Foundation, Inc. +.\" All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUT= ORS +.\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LI= MITED +.\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTIC= ULAR +.\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUT= ORS +.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR +.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF +.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINE= SS +.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN +.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) +.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF= THE +.\" POSSIBILITY OF SUCH DAMAGE. +.\" +.\" +.\" @(#)pwcache.3 8.1 (Berkeley) 6/9/93 +.\" +.Dd January 24, 2002 +.Dt PWCACHE 3 +.Os +.Sh NAME +.Nm pwcache , +.Nm user_from_uid , +.Nm group_from_gid +.Nd cache password and group entries +.Sh LIBRARY +.Lb libc +.Sh SYNOPSIS +.In pwd.h +.Ft const char * +.Fn user_from_uid "uid_t uid" "int nouser" +.Ft int +.Fn uid_from_user "const char *name" "uid_t *uid" +.Ft int +.Fn pwcache_userdb "int (*setpassent)(int)" "void (*endpwent)(void)" "stru= ct passwd * (*getpwnam)(const char *)" "struct passwd * (*getpwuid)(uid_t)" +.In grp.h +.Ft const char * +.Fn group_from_gid "gid_t gid" "int nogroup" +.Ft int +.Fn gid_from_group "const char *name" "gid_t *gid" +.Ft int +.Fn pwcache_groupdb "int (*setgroupent)(int)" "void (*endgrent)(void)" "st= ruct group * (*getgrnam)(const char *)" "struct group * (*getgrgid)(gid_t)" +.Sh DESCRIPTION +The +.Fn user_from_uid +function returns the user name associated with the argument +.Fa uid . +The user name is cached so that multiple calls with the same +.Fa uid +do not require additional calls to +.Xr getpwuid 3 . +If there is no user associated with the +.Fa uid , +a pointer is returned +to a string representation of the +.Fa uid , +unless the argument +.Fa nouser +is non-zero, in which case a +.Dv NULL +pointer is returned. +.Pp +The +.Fn group_from_gid +function returns the group name associated with the argument +.Fa gid . +The group name is cached so that multiple calls with the same +.Fa gid +do not require additional calls to +.Xr getgrgid 3 . +If there is no group associated with the +.Fa gid , +a pointer is returned +to a string representation of the +.Fa gid , +unless the argument +.Fa nogroup +is non-zero, in which case a +.Dv NULL +pointer is returned. +.Pp +The +.Fn uid_from_user +function returns the uid associated with the argument +.Fa name . +The uid is cached so that multiple calls with the same +.Fa name +do not require additional calls to +.Xr getpwnam 3 . +If there is no uid associated with the +.Fa name , +the +.Fn uid_from_user +function returns \-1; otherwise it stores the uid at the location pointed = to by +.Fa uid +and returns 0. +.Pp +The +.Fn gid_from_group +function returns the gid associated with the argument +.Fa name . +The gid is cached so that multiple calls with the same +.Fa name +do not require additional calls to +.Xr getgrnam 3 . +If there is no gid associated with the +.Fa name , +the +.Fn gid_from_group +function returns \-1; otherwise it stores the gid at the location pointed = to by +.Fa gid +and returns 0. +.Pp +The +.Fn pwcache_userdb +function changes the user database access routines which +.Fn user_from_uid +and +.Fn uid_from_user +call to search for users. +The caches are flushed and the existing +.Fn endpwent +method is called before switching to the new routines. +.Fa getpwnam +and +.Fa getpwuid +must be provided, and +.Fa setpassent +and +.Fa endpwent +may be +.Dv NULL +pointers. +.Pp +The +.Fn pwcache_groupdb +function changes the group database access routines which +.Fn group_from_gid +and +.Fn gid_from_group +call to search for groups. +The caches are flushed and the existing +.Fn endgrent +method is called before switching to the new routines. +.Fa getgrnam +and +.Fa getgrgid +must be provided, and +.Fa setgroupent +and +.Fa endgrent +may be +.Dv NULL +pointers. +.Sh SEE ALSO +.Xr getgrgid 3 , +.Xr getgrnam 3 , +.Xr getpwnam 3 , +.Xr getpwuid 3 +.Sh HISTORY +The +.Fn user_from_uid +and +.Fn group_from_gid +functions first appeared in +.Bx 4.4 . +.Pp +The +.Fn uid_from_user +and +.Fn gid_from_group +functions first appeared in +.Nx 1.4 . +.Pp +The +.Fn pwcache_userdb +and +.Fn pwcache_groupdb +functions first appeared in +.Nx 1.6 . Property changes on: contrib/libc-pwcache/pwcache.3 ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property --SFyWQ0h3ruR435lw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFQcwTOXY6L6fI4GtQRAqv3AJ9HcIq+qOjiznoPYF3P2A6C10yUfwCbBCK7 YNG7lGzMTDl3ladXaFFTSwk= =bQ/g -----END PGP SIGNATURE----- --SFyWQ0h3ruR435lw-- From owner-freebsd-arch@FreeBSD.ORG Mon Oct 8 17:00:15 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 17A9D106566C; Mon, 8 Oct 2012 17:00:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 742368FC18; Mon, 8 Oct 2012 17:00:12 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q98H0L8l054292; Mon, 8 Oct 2012 20:00:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q98H09iQ064671; Mon, 8 Oct 2012 20:00:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q98H09IC064670; Mon, 8 Oct 2012 20:00:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 8 Oct 2012 20:00:08 +0300 From: Konstantin Belousov To: Brooks Davis Message-ID: <20121008170008.GE35915@deviant.kiev.zoral.com.ua> References: <20121008165230.GD23400@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xsYrt8mWir//dmFZ" Content-Disposition: inline In-Reply-To: <20121008165230.GD23400@lor.one-eyed-alien.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-arch@freebsd.org Subject: Re: [CFT] Importing NetBSD's pwcache(3) 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: Mon, 08 Oct 2012 17:00:15 -0000 --xsYrt8mWir//dmFZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 08, 2012 at 11:52:30AM -0500, Brooks Davis wrote: > I'm planning to import NetBSD's implementation and expansion > of pwcache(3). The main feature is that it adds is the new > functions gid_from_group(), pwcache_userdb(), pwcache_groupdb(), and > uid_from_user(). The *_from_*() functions do what you'd expect. The > pwcache*() functions allow you to implement alternative lookup > functions. >=20 > NetBSD's mtree and install use them to support alternate master.passwd > and group files. They use it to support image creation on non-NetBSD > systems. In principle this could eliminate the need to run mergemaster > before installworld after a new user or group is added to the system > (assuming of course that the admin isn't randomly renumbering users and > groups). >=20 > If you wish to test this patch, apply it and then delete > lib/libc/gen/pwcache.[3c] so the new versions in contrib are found. >=20 > The actual commit will include a copy from > vendor/NetBSD/libc-pwcache/dist to contrib/libc-pwcache. I noted this first on the branch, but waited for the official announcement, so thank you for doing the notification in advance. I dislike the addition of the random and mostly single-use stuff to libc. In particular, it falls into the application namespace. More, part of the functionality sounds much like NSS, but it is not. Can this be added either to libutil or might be to libnetbsd perhaps ? BTW, patch looks reversed. --xsYrt8mWir//dmFZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlBzBpgACgkQC3+MBN1Mb4gDAwCg9+ht0aUD3x+DxpO5QvNGIq2B IZIAn2NDsRGJmoldkBl3Y0lYmW1stOr8 =Me5W -----END PGP SIGNATURE----- --xsYrt8mWir//dmFZ-- From owner-freebsd-arch@FreeBSD.ORG Mon Oct 8 17:10:29 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 BE7F21065673 for ; Mon, 8 Oct 2012 17:10:29 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 5A11D8FC12 for ; Mon, 8 Oct 2012 17:10:28 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id q98HAR3M034390; Mon, 8 Oct 2012 12:10:27 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id q98HAROG034389; Mon, 8 Oct 2012 12:10:27 -0500 (CDT) (envelope-from brooks) Date: Mon, 8 Oct 2012 12:10:27 -0500 From: Brooks Davis To: Konstantin Belousov Message-ID: <20121008171027.GE23400@lor.one-eyed-alien.net> References: <20121008165230.GD23400@lor.one-eyed-alien.net> <20121008170008.GE35915@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hwvH6HDNit2nSK4j" Content-Disposition: inline In-Reply-To: <20121008170008.GE35915@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@freebsd.org Subject: Re: [CFT] Importing NetBSD's pwcache(3) 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: Mon, 08 Oct 2012 17:10:29 -0000 --hwvH6HDNit2nSK4j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 08, 2012 at 08:00:08PM +0300, Konstantin Belousov wrote: > On Mon, Oct 08, 2012 at 11:52:30AM -0500, Brooks Davis wrote: > > I'm planning to import NetBSD's implementation and expansion > > of pwcache(3). The main feature is that it adds is the new > > functions gid_from_group(), pwcache_userdb(), pwcache_groupdb(), and > > uid_from_user(). The *_from_*() functions do what you'd expect. The > > pwcache*() functions allow you to implement alternative lookup > > functions. > >=20 > > NetBSD's mtree and install use them to support alternate master.passwd > > and group files. They use it to support image creation on non-NetBSD > > systems. In principle this could eliminate the need to run mergemaster > > before installworld after a new user or group is added to the system > > (assuming of course that the admin isn't randomly renumbering users and > > groups). > >=20 > > If you wish to test this patch, apply it and then delete > > lib/libc/gen/pwcache.[3c] so the new versions in contrib are found. > >=20 > > The actual commit will include a copy from > > vendor/NetBSD/libc-pwcache/dist to contrib/libc-pwcache. > I noted this first on the branch, but waited for the official announcemen= t, > so thank you for doing the notification in advance. >=20 > I dislike the addition of the random and mostly single-use stuff to libc. > In particular, it falls into the application namespace. > More, part of the functionality sounds much like NSS, but it is not. >=20 > Can this be added either to libutil or might be to libnetbsd perhaps ? I don't think this would make sense. user_from_uid() and group_from_gid() are already part of libc from 4.4 BSD for use by consumers such as ls and find so the cache needs to live there. Putting the other two functions in some other library would be absurd. > BTW, patch looks reversed. Nope. It's the result of the files moving to contrib. -- Brooks --hwvH6HDNit2nSK4j Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFQcwkDXY6L6fI4GtQRAuMqAJ95V0+L7FofItNgHmw5G5FnjpX0MACeO/Wu EGjklRqQkEUBgXyVdnoxYXk= =iPHk -----END PGP SIGNATURE----- --hwvH6HDNit2nSK4j-- From owner-freebsd-arch@FreeBSD.ORG Mon Oct 8 17:21:45 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 251C9106564A; Mon, 8 Oct 2012 17:21:45 +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 C84BF8FC0A; Mon, 8 Oct 2012 17:21:44 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa01.fnfis.com (8.14.4/8.14.4) with ESMTP id q98HLbOC032054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 8 Oct 2012 12:21:37 -0500 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.16) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 8 Oct 2012 12:21:36 -0500 MIME-Version: 1.0 (Apple Message framework v1283) From: Devin Teske In-Reply-To: <50726C73.10506@FreeBSD.org> Date: Mon, 8 Oct 2012 10:21:34 -0700 Message-ID: References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <5071D6B5.1010609@FreeBSD.org> <50726C73.10506@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-08_03:2012-10-08, 2012-10-08, 1970-01-01 signatures=0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 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: Mon, 08 Oct 2012 17:21:45 -0000 On Oct 7, 2012, at 11:02 PM, Doug Barton wrote: > On 10/07/2012 13:27, Devin Teske wrote: >>=20 >> On Oct 7, 2012, at 12:23 PM, Doug Barton wrote: >>=20 >> I reject your proposed hypothesis that this was my intent (the proper >> intent is described below). >>=20 >>=20 >>> "But that's not why I mentioned how many hours I spent." "So why >>> mention it at all?" :) >>>=20 >>=20 >> My precise intent for mentioning this was for the other Forth and/or >> boot-menu folks (not the casual person). >>=20 >> I didn't want the other Forth hackers to get excited and perhaps form >> the markedly false impressions that either: >>=20 >> b. that submenus were easy to add=20 >=20 > Right, you wanted us all to know how hard you worked. Re-casting the same aspersions (but removing or changing context so that th= ey look fresh) doesn't make them true, no matter how much you'd like them t= o be. I already explained (and you cut) the real impetus to my work. > Congratulations, > your efforts seem well received. >=20 Sarcasm. You've surely mastered this art. Recognize sir, that you are not t= he Lorax and thus you do not speak for the trees. >>> 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. >>=20 >> What name would you give this "all submenus" menu item?=20 >=20 > That works for me. >=20 Others have already come forth (no pun intended ^_^) and stated that this d= oes not work for them. Let's talk alternatives. I really like Alexander Leidinger's suggestions. ^_^ >> Because, as >> previously discussed, if the menu stays as-is, we can really only >> have one more item >=20 > You keep saying that your current code allows for 9. There are 7 > currently. Did I miss something? >=20 My code, sir (pay special attention to lines 436 and 437 -- especially 437 = in the context of 436, in the further context of 430-434): http://svnweb.freebsd.org/base/head/sys/boot/forth/menu.4th?revision=3D2224= 17&view=3Dmarkup 430 \ Note that any menu item beyond 9 will have a numerical prefix on the 431 \ screen consisting of the first digit (ie. 1 for the tenth menu item) 432 \ and the key required to activate that menu item will be the decimal 433 \ ASCII of 48 plus the menu item (ie. 58 for the tenth item, aka. `:') 434 \ which is misleading and not desirable. 435 \=20 436 \ Thus, we do not allow more than 8 configurable items on the menu 437 \ (with "Reboot" as the optional ninth and highest numbered item). In addition, in this very thread, I've said: From: http://lists.freebsd.org/pipermail/freebsd-arch/2012-October/013202.h= tml "Each submenu can have up to 9 maximum (tho we like to keep it at 8 for mul= tiple reasons) menu items." To explain further: + Yes, menus can have 9 items + No, they cannot have 9 **configurable** menu items + The 9th slot is for an optional built-in "Reboot" menu item And furthermore: A problem arises when: a. $menu_options is set (injecting a "Options:" -- text configurable -- vis= ible separator) b. $menu_reboot is set (injecting the aforementioned "Reboot" built-in) c. All 8 configurable menu items are configured Then the menu area is too small (imho) to accommodate the menu because the = 9th menu item then bumps up against the bottom border (largely because of t= he $menu_options separator which didn't exist when I originally designed th= e layout). >> 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). >=20 > Given how few people will be using anything other than what is at the > top level, I doubt it. However, given that we can have 9 more menu items > on the second page of menus, 8 really. The 9th item is not configurable (unless you ask very nicely and = then I'll put the time and effort in to make-it-so). > why not have a few of the more popular > items at the top, and then more submenus below? I really like the idea that Alexander Leidinger had, which was to move "Boo= t Single User Mode" up to the "actions section" of the main menu. I slept on this and it has the very nice side-effect of changing the instru= ctions for entering single-user mode _BACK_ to the way it was 16+ months ag= o _before_ the introduction of my stateful-menu. In other words, moving "Boot Single User Mode" from a boolean option to an = action item, the instructions for entering SUM change from (currently): Press 's' then 'ENTER' back to the ol': Press 's' Tho, unlike the old days, we retain the shiny ability to do things like ver= bose-SUM with these simple instructions: Press 'v' then 's' (couldn't do things like that 16+ months ago with the old stateless-menu) > That's what is going to > happen on the first menu page, so the UI will be consistent. >=20 >>> Bonus points if you can make it easy to add a submenu via >>> loader.conf. >>>=20 >>=20 >> Done. There's zero difference in configuring menus in a "menu.rc" >> file than in "loader.conf" file. >=20 > 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? >=20 Gladly! Thank you for asking! I'll post the 4 different "menu.rc" files that I am planning on demonstrati= ng this Thursday at BAFUG. Please find attached the following files (with accompanying descriptions be= low): 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 tha= t 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" (fo= r 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 oth= er words, don't get too exciting about the *actual* menu items, get more ex= cited about "what the menu can do" by this example. This example goes to sh= ow that (if we need it), we can accommodate "cycling" menu items (where a s= ingle 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 config= ured item, it cycles back to the first. The text for these cyclic menu item= s (just like toggle menu items) are completely arbitrary (explaining that t= he "1of2" and "2of2" etc. text is configurable). NOTE: The next example consists of two files. The menu.rc _and_ a very smal= l 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 mi= micking what *ought* to instead be a series of C callbacks exposed to the F= ICL 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 m= enu *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 e= xample, 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 b= y 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 pass= ed into the menu as a callback, configured via appropriately-named environm= ent variables). What's imperative to see in the demo of these 4 menu.rc files is that no Fo= rth needs to be changed. Just drop in the appropriate menu.rc and reboot (S= EE BELOW WARNING!) WARNING!!! as previously explained,=85 you _MUST_ have the patches that I s= ent to avg and mav to be able to "just drop in these menu.rc files and rebo= ot" -- if you drop anything but the HEAD menu.rc into a HEAD copy of /boot = =85 you=85 will=85 not=85 boot=85 !!! For a copy of what I sent to avg and mav, check out my twitter account or d= rop me a line. >>> Regarding the UI on your submenu example; never, ever, ever use=20 >>> Backspace to mean anything other than "delete the character behind >>> the cursor." >>=20 >> Seriously? Who made _that_ rule? and moreover, _WHY_? >=20 > Um, if you don't already know the answers, I really can't help you. Ok, so you're no chaplain. I get that. > Go > get a book on how to right proper user interfaces. >=20 Great men have often told me: The most influential thing you can do in another's life is often to=85 =85 recommand a book =85 Think about that (and let's ignore the fact that you assume I have read no = books on UI design). Truth be told, I read the *best* book on UI design. Apple's historical/old = HIG. And if you laugh at that, I ask you =85 what other 700+ page book on U= I design is more comprehensive? I don't know if the current HIG is 700+ pag= es (in fact, I think they reduced the size when they jumped to OS X and hav= e since 1998 been reducing the size), BUT... when I read the HIG (front-to-= back) in the late-80's/early-90's =85 it was a *compendium* that could give= your foot a riotous-pain if you dropped it from a short height on one's un= shielded hoof. Backspace *IS* less than ideal, but you neither produced any arguments, nor= did you place yourself on any grounds that would take you seriously. Nonet= heless, I will take you seriously. I will admit that keyboards (and their manufacturers) are the culprit that = drives this need to stay away from "Backspace." Some keyboards physically s= ay "Delete" instead of "Backspace". Therefore, presenting a UI that says "B= ackspace" might confuse people when (say) they have an Apple English US key= board that has no "Backspace" (but instead a "Delete"). You'll also get zero argument out of me that putting "Delete" on-screen is = not only to-be-avoided for the opposing situation (that some keyboards may = not have a "Delete" but instead "Backspace") but indeed "Delete" is worse b= ecause the implied connotation associated with the "Delete" key (_someone_ = might be confused into thinking "Delete" will purge the menu from memory). I will play with keycodes. Just be aware that currently left arrow CANNOT work. That is a bad suggesti= on (read why below). In Forth, I'm using the "key" primitive which -- rather unfortunately -- pr= oduces a zero for "left-arrow", "right-arrow", "up-arrow", "down-arrow", "F= 1", "F2", "F3", "F4", "F5", "F6", "F7", "F8", "F9", and "F10" (note: it doe= sn't catch "F11", "F12", "F13", "F14", "F15", or "F16"). So all those key options are right-out when it comes to "using them instead= of Backspace" (I simply can't identify in the loader when those keys are p= ressed). > Meanwhile, I've no objection to the idea of having move "safe mode" to a > submenu, if that's the consensus. I don't think we should move ACPI > because users who need to enable that option are already having enough > problems as it is. >=20 Alexander Leidinger suggested (paraphrasing): 1. Boot 2. Escape to prompt 3. Reboot 4. Boot Single-User (separator) 5. Boot options 6. Root device (future) Sounds like you're suggesting: 1. Boot 2. Escape to prompt 3. Reboot (separator) 4. ACPI Mode 5. Boot Single User 6. Boot options 7. Root device (future) When I think about what you said (ACPI being used often), I question=85 Are there really people that need to be fiddling with this option on a per-= boot basis _OR_ are these people simply going into loader.conf(5) and making a permanent se= lection if-and-when they have a problem? thoughts? --=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. From owner-freebsd-arch@FreeBSD.ORG Mon Oct 8 17:40:31 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 21564106566C for ; Mon, 8 Oct 2012 17:40:31 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id DED0F8FC0C for ; Mon, 8 Oct 2012 17:40:30 +0000 (UTC) Received: from sa-nc-cs-116.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q98HeTeg083426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 8 Oct 2012 10:40:30 -0700 (PDT) (envelope-from marcel@xcllnt.net) From: Marcel Moolenaar Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <83AE27A6-C844-4720-99E7-A12106F77227@xcllnt.net> Date: Mon, 8 Oct 2012 10:40:23 -0700 To: "freebsd-arch@freebsd.org Arch" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: mmap and resource limits 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: Mon, 08 Oct 2012 17:40:31 -0000 All, What's the progress of mmap(2) doing resource accounting and it respecting resource limits? -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Mon Oct 8 17:41:20 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 65E8D1065674; Mon, 8 Oct 2012 17:41:20 +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 0D0E18FC20; Mon, 8 Oct 2012 17:41:19 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa04.fnfis.com (8.14.4/8.14.4) with ESMTP id q98HfHqb027778 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 8 Oct 2012 12:41:18 -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; Mon, 8 Oct 2012 12:40:46 -0500 MIME-Version: 1.0 (Apple Message framework v1283) From: Devin Teske In-Reply-To: Date: Mon, 8 Oct 2012 10:40:41 -0700 Message-ID: <5318C0C7-5534-4633-8F4C-40C106CFF0FE@fisglobal.com> References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <5071D6B5.1010609@FreeBSD.org> <50726C73.10506@FreeBSD.org> To: Devin Teske 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-08_03:2012-10-08, 2012-10-08, 1970-01-01 signatures=0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Doug Barton , 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: Mon, 08 Oct 2012 17:41:20 -0000 Oops=85 This time with the attachments (below). NOTE: Don't forget to diff each one to see how we go from what's in HEAD to= day to each other demo NOTE: vimdiff works better than diff, because it can highlight the differen= ces *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. >>>>=20 >>>=20 >>> Done. There's zero difference in configuring menus in a "menu.rc" >>> file than in "loader.conf" file. >>=20 >> 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? >>=20 >=20 > Gladly! Thank you for asking! >=20 > I'll post the 4 different "menu.rc" files that I am planning on demonstra= ting this Thursday at BAFUG. >=20 > Please find attached the following files (with accompanying descriptions = below): >=20 > menu.rc.1.current-head > This is what is in HEAD, CURRENT, and RELENG_9 **right now** >=20 > NOTE: Each of the following menu.rc examples *require* the new patchset t= hat 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). >=20 > menu.rc.2.submenu-head > This is the menu.rc file that replicates the images posted at the beginni= ng of this thread. > Though, currently, I'm thinking I ought to craft a new menu.rc to show wh= at Alexander Leidinger proposes. >=20 > menu.rc.3.submenu-cycler > This menu.rc shows things that DruidBSD offers (but FreeBSD cannot). In o= ther 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 usabl= e states). These menu items "cycle" -- meaning when you reach the last conf= igured item, it cycles back to the first. The text for these cyclic menu it= ems (just like toggle menu items) are completely arbitrary (explaining that= the "1of2" and "2of2" etc. text is configurable). >=20 > NOTE: The next example consists of two files. The menu.rc _and_ a very sm= all devicemenu.4th file which serves as a stand-in for C callbacks. In othe= r 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 >=20 > menu.rc.4.submenu-dynamic > devicemenu.4th >=20 > 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 item= s themselves are dynamically generated at runtime). >=20 > 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 plac= e where the C code exposes FICL constructs -- which ultimately are to be pa= ssed into the menu as a callback, configured via appropriately-named enviro= nment variables). >=20 > 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!) >=20 > WARNING!!! as previously explained,=85 you _MUST_ have the patches that I= sent to avg and mav to be able to "just drop in these menu.rc files and re= boot" -- if you drop anything but the HEAD menu.rc into a HEAD copy of /boo= t =85 you=85 will=85 not=85 boot=85 !!! >=20 > For a copy of what I sent to avg and mav, check out my twitter account or= drop me a line. --=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. From owner-freebsd-arch@FreeBSD.ORG Mon Oct 8 17:53:33 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 248861065672; Mon, 8 Oct 2012 17:53:33 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by mx1.freebsd.org (Postfix) with ESMTP id 93A3A8FC0A; Mon, 8 Oct 2012 17:53:32 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUHMTFuN/OztzHaNlesQefUfbVerSwTPG@postini.com; Mon, 08 Oct 2012 10:53:32 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 8 Oct 2012 10:52:06 -0700 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q98Hq6h01030; Mon, 8 Oct 2012 10:52:06 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 5961858094; Mon, 8 Oct 2012 10:52:06 -0700 (PDT) To: Brooks Davis In-Reply-To: <20121008154853.GC23400@lor.one-eyed-alien.net> References: <20121007001423.9878F58094@chaos.jnpr.net> <20121008154853.GC23400@lor.one-eyed-alien.net> Comments: In-reply-to: Brooks Davis message dated "Mon, 08 Oct 2012 10:48:53 -0500." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Mon, 8 Oct 2012 10:52:06 -0700 Message-ID: <20121008175206.5961858094@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-arch@freebsd.org Subject: Re: bsd.own.mk - just let WITHOUT_* take precedence 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: Mon, 08 Oct 2012 17:53:33 -0000 On Mon, 8 Oct 2012 10:48:53 -0500, Brooks Davis writes: >I'm not sure if I agree or not, I'll have to think more. This sort of >thing that leads to me yelling at my computer "but I @#%$@# set >WITH_FOO you ^@$@! machine." :) For default YES options, WITHOUT_ already takes precedence (ignoring the fact that you die first if both are set). The main change is to make default NO options behave the same. >I think we should at a minimum issue a warning and say what we did. Sure, something like: .warning both WITHOUT_${var} and WITH_${var} set; WITHOUT_${var} wins. >The implementation looks mostly fine. I do think it skips some options >with variable defaults (LIBCXX in HEAD for example) so I think you'd need >to sprinkle more of these changes in. True, here's a more complte change: Index: share/mk/bsd.own.mk =================================================================== --- share/mk/bsd.own.mk (revision 241871) +++ share/mk/bsd.own.mk (working copy) @@ -469,7 +469,7 @@ __DEFAULT_NO_OPTIONS+=FDT # .for var in ${__DEFAULT_YES_OPTIONS} .if defined(WITH_${var}) && defined(WITHOUT_${var}) -.error WITH_${var} and WITHOUT_${var} can't both be set. +.warning both WITH_${var} and WITHOUT_${var} set; WITHOUT_${var} wins. .endif .if defined(MK_${var}) .error MK_${var} can't be set by a user. @@ -487,12 +487,12 @@ MK_${var}:= yes # .for var in ${__DEFAULT_NO_OPTIONS} .if defined(WITH_${var}) && defined(WITHOUT_${var}) -.error WITH_${var} and WITHOUT_${var} can't both be set. +.warning both WITH_${var} and WITHOUT_${var} set; WITHOUT_${var} wins. .endif .if defined(MK_${var}) .error MK_${var} can't be set by a user. .endif -.if defined(WITH_${var}) +.if defined(WITH_${var}) && !defined(WITHOUT_${var}) MK_${var}:= yes .else MK_${var}:= no @@ -609,7 +609,7 @@ MK_CLANG_IS_CC:= no PAM \ WIRELESS .if defined(WITH_${var}_SUPPORT) && defined(WITHOUT_${var}_SUPPORT) -.error WITH_${var}_SUPPORT and WITHOUT_${var}_SUPPORT can't both be set. +.warning both WITH_${var}_SUPPORT and WITHOUT_${var}_SUPPORT set; WITHOUT_${var}_SUPPORT wins. .endif .if defined(MK_${var}_SUPPORT) .error MK_${var}_SUPPORT can't be set by a user. @@ -628,15 +628,15 @@ MK_${var}_SUPPORT:= yes GSSAPI/KERBEROS \ MAN_UTILS/MAN .if defined(WITH_${vv:H}) && defined(WITHOUT_${vv:H}) -.error WITH_${vv:H} and WITHOUT_${vv:H} can't both be set. +.warning both WITH_${vv:H} and WITHOUT_${vv:H} set; WITHOUT_${vv:H} wins. .endif .if defined(MK_${vv:H}) .error MK_${vv:H} can't be set by a user. .endif -.if defined(WITH_${vv:H}) +.if defined(WITHOUT_${vv:H}) +MK_${vv:H}:= no +.elif defined(WITH_${vv:H}) MK_${vv:H}:= yes -.elif defined(WITHOUT_${vv:H}) -MK_${vv:H}:= no .else MK_${vv:H}:= ${MK_${vv:T}} .endif @@ -649,7 +649,7 @@ MK_${vv:H}:= ${MK_${vv:T}} .for var in \ LIBCPLUSPLUS .if defined(WITH_${var}) && defined(WITHOUT_${var}) -.error WITH_${var} and WITHOUT_${var} can't both be set. +.warning both WITH_${var} and WITHOUT_${var} set; WITHOUT_${var} wins. .endif .if defined(MK_${var}) .error MK_${var} can't be set by a user. @@ -661,7 +661,7 @@ MK_${var}:= no MK_${var}:= yes .endif .else -.if defined(WITH_${var}) +.if defined(WITH_${var}) && !defined(WITHOUT_${var}) MK_${var}:= yes .else MK_${var}:= no From owner-freebsd-arch@FreeBSD.ORG Tue Oct 9 09:12:36 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 6883C643 for ; Tue, 9 Oct 2012 09:12:36 +0000 (UTC) (envelope-from joella@brembrolo.com) Received: from host9.shoppepro.com (host9.shoppepro.com [50.28.10.151]) by mx1.freebsd.org (Postfix) with ESMTP id AC2D78FC45 for ; Tue, 9 Oct 2012 07:56:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brembrolo.com; s=default; h=Date:Reply-To:Content-Type:Content-Transfer-Encoding:To:Subject:From; bh=ZIP+Wwc9Ab8/OGVNrQFZ8h998ebLS9qBg7unegFCt90=; b=I60B4lKvL07nKdqvLZSbbFVGnWqr0XuiqyzEY77aQCpEJKkhckpox72sULLiial6NctK5HzdblM3Pbe4391/OPn+6Nvyk2GK0pLcyHIM21UxrIvUTtsSTfeHjLuSlMaF; Received: from 111-255-27-132.dynamic.hinet.net ([111.255.27.132]:3988 helo=brembrolo.com) by host9.shoppepro.com with esmtpa (Exim 4.80) (envelope-from ) id 1TLOVf-0008NY-Qu for freebsd-arch@freebsd.org; Mon, 08 Oct 2012 18:21:24 -0700 From: Anita =?UTF-8?B?S2FsxJNqYQ==?= Subject: Freebsd-arch, =?UTF-8?B?bcSBamFz?= lapa =?UTF-8?B?a8SB?= reiz Tev.. To: freebsd-arch@freebsd.org Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" Date: Mon, 8 Oct 2012 18:20:51 -0700 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host9.shoppepro.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brembrolo.com Message-Id: <20121009091236.6883C643@hub.freebsd.org> X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Anita =?UTF-8?B?S2FsxJNqYQ==?= List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 09:12:36 -0000 LabrÄ«t, Freebsd-arch! Palasi to te interesanto komerc - portÄlu: http://bajozitox.freeiz.com/ozecomo.html BlogÄ ir tik tieÅ¡Äm pamÄcoÅ¡a (pat ļoti) saruna ar puisi , kurÅ¡ salÄ«dzinoÅ¡i Ä«sÄ laikÄ nopelnÄ«ja baigos lÄ«dzekļus. MÄjas lapÄ pat ir rakstÄ«ts kÄ viņš to paveica - noteikti izlasi un pamÄ“Ä£ini , ja gribi bÅ«t veiksmÄ«gs cilvÄ“ks! Anita KalÄ“ja From owner-freebsd-arch@FreeBSD.ORG Tue Oct 9 09:47:19 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 57DABB67; Tue, 9 Oct 2012 09:47:19 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0CF4E8FC20; Tue, 9 Oct 2012 09:47:18 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id A84225C59; Tue, 9 Oct 2012 11:47:11 +0200 (CEST) Message-ID: <5073F29D.6060505@FreeBSD.org> Date: Tue, 09 Oct 2012 11:47:09 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121002 Thunderbird/16.0 MIME-Version: 1.0 To: d@delphij.net Subject: Re: Building environment using system headers instead of the in-tree headers References: <50736C5A.1000604@delphij.net> In-Reply-To: <50736C5A.1000604@delphij.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Xin Li , peter@freebsd.org, freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 09:47:19 -0000 On 2012-10-09 02:14, Xin Li wrote: > Josh Paetzel recently discovered an interesting build issue with the > current FreeBSD 'buildworld', where 'make buildworld' over a FreeBSD > 9.0 tree on a FreeBSD 9.1 system will fail. > > As it turns out, this was caused by addition of xlocale functionality > on FreeBSD 9.1, which uses macros and expects some new functions found > in more recent FreeBSD releases. On the other hand, we do not pass > e.g. -I${.CURDIR}/../../include so the header is preferred than system > header. During which stage does this fail? In the '4.2 building libraries' one? > So an obvious way to get around this would be to add that to CFLAGS. > It looks like that in r81600 Peter have "sneak in" such change in libc > because the FILE structure was changed and we have to use that to get > the code compile. It shouldn't be needed, if the cross-tools stage completed successfully. The toolchain built there will *only* look in the /usr/obj directory for its headers. Of course, if you are manually running make in lib/libc, then all bets are off. :) I think there is always a way to shoot yourself in the foot then. From owner-freebsd-arch@FreeBSD.ORG Tue Oct 9 14:38: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 B9C372AF; Tue, 9 Oct 2012 14:38:12 +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 529E48FC14; Tue, 9 Oct 2012 14:38:11 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so6854625oag.13 for ; Tue, 09 Oct 2012 07:38:11 -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; bh=Anq1eGLNVV7qdSN+1q2f0hPxjyHHFKZUXyrhNTqwjFE=; b=PsKNpwxE7+VruKCaofiHuZ6mBeUq7A1bzeCBnZa6J3QvYFb+7rhKNWxSScJRfBsggM Gh3UubHmxuAYYVYyQk7yE9PQCAucJdm51AQPbADq2eO1BzhFhO7rvwATMh4/YefJAG7d W9t9OjwYCc1xl6KoEbG2Dd/4gXF48xN1xVoJ7Uhi722nAFpp8xAvsXs/OADGOP4Q81G6 Vgzg48TfvMtxTSlMUulX/Nvnht027zn0qS2MVA8qngpqihVoOzEEjUtwesG7aRvNCC4s nsp5T9DeIeW07YhouQ28/KEgJz4cc7Umw1SCKcoZgfaDTotCjyv9M1zMa3ZvT33+4oaN btGw== MIME-Version: 1.0 Received: by 10.182.54.103 with SMTP id i7mr3007722obp.62.1349793491299; Tue, 09 Oct 2012 07:38:11 -0700 (PDT) Received: by 10.76.167.202 with HTTP; Tue, 9 Oct 2012 07:38:11 -0700 (PDT) In-Reply-To: <5073F29D.6060505@FreeBSD.org> References: <50736C5A.1000604@delphij.net> <5073F29D.6060505@FreeBSD.org> Date: Tue, 9 Oct 2012 07:38:11 -0700 Message-ID: Subject: Re: Building environment using system headers instead of the in-tree headers From: Garrett Cooper To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Cc: Xin Li , d@delphij.net, peter@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 14:38:12 -0000 On Tue, Oct 9, 2012 at 2:47 AM, Dimitry Andric wrote: > On 2012-10-09 02:14, Xin Li wrote: >> >> Josh Paetzel recently discovered an interesting build issue with the >> current FreeBSD 'buildworld', where 'make buildworld' over a FreeBSD >> 9.0 tree on a FreeBSD 9.1 system will fail. FWIW I remember when I used to "meister" builds on build.ix there was something off about the machine's setup dealing with the headers. I didn't narrow down what exactly it was, but I had a hunch it was build environment (machine) related (and I think my explanation might make sense) as I never ran into the same issue with streetfighter.ix (which ran CURRENT) or bayonetta, my personal workstation (which has run 8-CURRENT and 9-CURRENT and 9/stable since then). Full logs with build errors along with repro steps would help too if they exist... >> As it turns out, this was caused by addition of xlocale functionality >> on FreeBSD 9.1, which uses macros and expects some new functions found >> in more recent FreeBSD releases. On the other hand, we do not pass >> e.g. -I${.CURDIR}/../../include so the header is preferred than system >> header. > > > During which stage does this fail? In the '4.2 building libraries' one? ... Doing a quick grep and given past experience in Linux embedded projects, isn't the real problem that we're not using gcc properly and it's picking up the wrong system root path (for the system directory #includes)? stable/6 (just for fun and to verify whether or not there was something lost in the gcc 4.2.1 merge): $ egrep --include Makefile\* --include \*.mk -r '(iwithprefix|iwithprefixbefore|isystem|isysroot|nostdinc)' .; egrep --include \*.h -r '(iwithprefix|iwithprefixbefore|isystem|isysroot|nostdinc)' contrib/ ./share/mk/bsd.dep.mk:MKDEP_CFLAGS= ${CFLAGS:M-nostdinc*} ${CFLAGS:M-[BID]*} ./share/mk/bsd.dep.mk:MKDEP_CXXFLAGS= ${CXXFLAGS:M-nostdinc*} ${CXXFLAGS:M-[BID]*} ./share/mk/bsd.dep.mk:MKDEP_OBJCFLAGS=${OBJCFLAGS:M-nostdinc*} ${OBJCFLAGS:M-[BID]*} ${OBJCFLAGS:M-Wno-import*} ./sys/conf/kmod.mk:NOSTDINC= -nostdinc ./sys/conf/kern.pre.mk:NOSTDINC= -nostdinc contrib/binutils/libiberty/cp-demangle.h: Written by Ian Lance Taylor . contrib/gcc/cp-demangle.h: Written by Ian Lance Taylor . contrib/gcc/config/sol2.h:%{compat-bsd:-iwithprefixbefore ucbinclude -I/usr/ucbinclude} \ contrib/gcc/config/i386/sco5.h: header files. Hence the -isystem /usr/gnu/include in the CPP_SPEC. contrib/gcc/config/i386/sco5.h: -isystem /usr/gnu/include \ contrib/gcc/config/i386/sco5.h: %{ansi:-isystem include/ansi%s -isystem /usr/include/ansi} \ contrib/gcc/config/i386/sco5.h: %{posix:-isystem include/posix%s -isystem /usr/include/posix \ contrib/gcc/config/i386/sco5.h: %{!posix:%{Xpg4:-isystem include/xpg4%s -isystem /usr/include/xpg4 \ contrib/gcc/config/i386/sco5.h: %{Xods30:-isystem include/ods_30_compat%s \ contrib/gcc/config/i386/sco5.h: -isystem /usr/include/ods_30_compat \ contrib/gcc/config/i386/cygwin.h: %{!nostdinc:%{!mno-win32|mno-cygwin:-idirafter ../include/w32api%s -idirafter ../../include/w32api%s}}\ contrib/gcc/config/i386/i386-interix.h:-isystem %$INTERIX_ROOT/usr/include" contrib/gcc/gcc.h: || !strcmp (STR, "iwithprefix") || !strcmp (STR, "iwithprefixbefore") \ contrib/gcc/gcc.h: || !strcmp (STR, "isystem") || !strcmp (STR, "-param") \ stable/9: $ egrep --include Makefile\* --include \*.mk -r '(iwithprefix|iwithprefixbefore|isystem|isysroot|nostdinc)' .; egrep --include \*.h -r '(iwithprefix|iwithprefixbefore|isystem|isysroot|nostdinc)' contrib/ ./sys/conf/kmod.mk:NOSTDINC= -nostdinc ./sys/conf/kern.pre.mk:NOSTDINC= -nostdinc ./share/mk/bsd.dep.mk:MKDEP_CFLAGS= ${CFLAGS:M-nostdinc*} ${CFLAGS:M-[BIDU]*} ${CFLAGS:M-std=*} \ ./share/mk/bsd.dep.mk:MKDEP_CXXFLAGS= ${CXXFLAGS:M-nostdinc*} ${CXXFLAGS:M-[BIDU]*} \ contrib/gcclibs/libiberty/cp-demangle.h: Written by Ian Lance Taylor . contrib/llvm/tools/clang/include/clang/Serialization/ASTReader.h: std::string isysroot; contrib/llvm/tools/clang/include/clang/Serialization/ASTReader.h: /// \param isysroot If non-NULL, the system include path specified by the contrib/llvm/tools/clang/include/clang/Serialization/ASTReader.h: ASTReader(Preprocessor &PP, ASTContext &Context, StringRef isysroot = "", contrib/llvm/tools/clang/include/clang/Serialization/ASTWriter.h: void WriteMetadata(ASTContext &Context, StringRef isysroot, contrib/llvm/tools/clang/include/clang/Serialization/ASTWriter.h: StringRef isysroot); contrib/llvm/tools/clang/include/clang/Serialization/ASTWriter.h: void WriteHeaderSearch(const HeaderSearch &HS, StringRef isysroot); contrib/llvm/tools/clang/include/clang/Serialization/ASTWriter.h: StringRef isysroot, const std::string &OutputFile, contrib/llvm/tools/clang/include/clang/Serialization/ASTWriter.h: /// \param isysroot if non-empty, write a relocatable file whose headers contrib/llvm/tools/clang/include/clang/Serialization/ASTWriter.h: Module *WritingModule, StringRef isysroot, contrib/llvm/tools/clang/include/clang/Serialization/ASTWriter.h: std::string isysroot; contrib/llvm/tools/clang/include/clang/Serialization/ASTWriter.h: StringRef isysroot, raw_ostream *Out); contrib/llvm/tools/clang/include/clang/Frontend/HeaderSearchOptions.h: /// it should be) because that is false for user provided '-iwithprefix' contrib/binutils/libiberty/cp-demangle.h: Written by Ian Lance Taylor . contrib/gcc/config/i386/i386-interix.h:-isystem %$INTERIX_ROOT/usr/include" contrib/gcc/config/i386/sco5.h: header files. Hence the -isystem /usr/gnu/include in the CPP_SPEC. contrib/gcc/config/i386/sco5.h: -isystem /usr/gnu/include \ contrib/gcc/config/i386/sco5.h: %{ansi:-isystem include/ansi%s -isystem /usr/include/ansi} \ contrib/gcc/config/i386/sco5.h: %{posix:-isystem include/posix%s -isystem /usr/include/posix \ contrib/gcc/config/i386/sco5.h: %{!posix:%{Xpg4:-isystem include/xpg4%s -isystem /usr/include/xpg4 \ contrib/gcc/config/i386/sco5.h: %{Xods30:-isystem include/ods_30_compat%s \ contrib/gcc/config/i386/sco5.h: -isystem /usr/include/ods_30_compat \ contrib/gcc/config/i386/cygwin.h: %{!nostdinc:%{!mno-win32|mno-cygwin:-idirafter ../include/w32api%s -idirafter ../../include/w32api%s}}\ contrib/gcc/config/vxworksae.h: %{!nostdinc:%{isystem*}} \ contrib/gcc/config/vxworksae.h: %{!nostdinc:-isystem " VXWORKSAE_TARGET_DIR "/vThreads/h}} \ contrib/gcc/config/vxworksae.h: %{!nostdinc:-isystem " VXWORKSAE_TARGET_DIR "/h}} \ contrib/gcc/config/vxworksae.h: %{!nostdinc:-isystem " VXWORKSAE_TARGET_DIR "/val/h}" contrib/gcc/config/sol2.h:%{compat-bsd:-iwithprefixbefore ucbinclude -I/usr/ucbinclude} \ contrib/gcc/config/darwin.h: "%{isysroot*:-syslibroot %*;:-syslibroot " TARGET_SYSTEM_ROOT "}" contrib/gcc/config/darwin.h:#define LINK_SYSROOT_SPEC "%{isysroot*:-syslibroot %*}" contrib/gcc/config/vxworks.h:/* Since we provide a default -isystem, expand -isystem on the command contrib/gcc/config/vxworks.h: %{!nostdinc:%{isystem*}} \ contrib/gcc/config/vxworks.h: %{!nostdinc:-isystem " VXWORKS_TARGET_DIR "/usr/h}} \ contrib/gcc/config/vxworks.h: %{!nostdinc:-isystem " VXWORKS_TARGET_DIR "/h}}" contrib/gcc/config/sol2-6.h:%{compat-bsd:-iwithprefixbefore ucbinclude -I/usr/ucbinclude} \ contrib/gcc/gcc.h: || !strcmp (STR, "iwithprefix") || !strcmp (STR, "iwithprefixbefore") \ contrib/gcc/gcc.h: || !strcmp (STR, "iquote") || !strcmp (STR, "isystem") \ contrib/gcc/gcc.h: || !strcmp (STR, "isysroot") \ contrib/gcc/c-incpath.h: /* Do extra includes processing. STDINC is false iff -nostdinc was given. */ $ If so, Makefile.inc1 needs to do the right thing by passing through a combination of those CFLAGS/CXXFLAGS to clang/gcc/etc. As Dimitry said, building from the subdirectory without going through the build system should not necessarily work if the headers are not "API" (function declaration, #include pollution, macro declaration, etc) compatible unless you install the headers to the system directory (/usr/include) first. Thanks! -Garrett From owner-freebsd-arch@FreeBSD.ORG Tue Oct 9 14:44:40 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 88CDF428; Tue, 9 Oct 2012 14:44:40 +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 22BCA8FC1B; Tue, 9 Oct 2012 14:44:39 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so6865522oag.13 for ; Tue, 09 Oct 2012 07:44:39 -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; bh=Kf7cvtMo9a4Zl/vGe5ff5o2hXhT19xgZkEZH8btK03A=; b=r+O8sQrw57ZtrLLUl9qcuo62n3buBPJGan/Z0nbBSHIFTqsKlwom9tmEGb5dwbo07e OURdO7ZQAPxB/OzhRwXKZM+fME4+p0sypOvia/mcckldzNC5/X0mwKh6qLtdTBp3fuWv Ou/KrIt1TCmoMSLH/h+0NKGd1lyrTAHrNCXlEVe1NUxrvqBCznCoFMphDF3eze9Ei1Po wjDhCDsk9bcbl5JYebYOyBFhKSd6tEuK7C21/DrI7EkOHByEdlBlSo9nkAucHNbK5B2Y 9pMuwnPfqQHQImbN6hOrPoB5NPlPuyCmEa67k9A9uMue+/se+4lFAwEn/Jx1Z4wVX7/M 7OlA== MIME-Version: 1.0 Received: by 10.182.10.6 with SMTP id e6mr3025952obb.16.1349793879546; Tue, 09 Oct 2012 07:44:39 -0700 (PDT) Received: by 10.76.167.202 with HTTP; Tue, 9 Oct 2012 07:44:39 -0700 (PDT) In-Reply-To: References: <50736C5A.1000604@delphij.net> <5073F29D.6060505@FreeBSD.org> Date: Tue, 9 Oct 2012 07:44:39 -0700 Message-ID: Subject: Re: Building environment using system headers instead of the in-tree headers From: Garrett Cooper To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Cc: Xin Li , d@delphij.net, peter@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 14:44:40 -0000 On Tue, Oct 9, 2012 at 7:38 AM, Garrett Cooper wrote: > On Tue, Oct 9, 2012 at 2:47 AM, Dimitry Andric wrote: >> On 2012-10-09 02:14, Xin Li wrote: >>> >>> Josh Paetzel recently discovered an interesting build issue with the >>> current FreeBSD 'buildworld', where 'make buildworld' over a FreeBSD >>> 9.0 tree on a FreeBSD 9.1 system will fail. > > FWIW I remember when I used to "meister" builds on build.ix there was > something off about the machine's setup dealing with the headers. I > didn't narrow down what exactly it was, but I had a hunch it was build > environment (machine) related (and I think my explanation might make > sense) as I never ran into the same issue with streetfighter.ix (which > ran CURRENT) or bayonetta, my personal workstation (which has run > 8-CURRENT and 9-CURRENT and 9/stable since then). > > Full logs with build errors along with repro steps would help too if > they exist... The .depend file for the directory would be nice too as well as the filesystem type for the MAKEOBJDIRPREFIX. Thanks, -Garrett From owner-freebsd-arch@FreeBSD.ORG Tue Oct 9 15:06:00 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 11E2DC81; Tue, 9 Oct 2012 15:06:00 +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 C3B688FC0C; Tue, 9 Oct 2012 15:05:58 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa05.fnfis.com (8.14.4/8.14.4) with ESMTP id q99F5uVJ003487 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 9 Oct 2012 10:05:58 -0500 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.31) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 9 Oct 2012 10:05:56 -0500 Subject: Re: New Boot Loader Menu MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Devin Teske In-Reply-To: <50732CB1.9080900@gmx.de> Date: Tue, 9 Oct 2012 08:05:52 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <71571815-CBF3-4B16-BA77-2828B8BA613C@fisglobal.com> References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <5071D6B5.1010609@FreeBSD.org> <50726C73.10506@FreeBSD.org> <50732CB1.9080900@gmx.de> To: olli hauer 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-09_05:2012-10-09,2012-10-09,1970-01-01 signatures=0 Cc: Devin Teske , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 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: Tue, 09 Oct 2012 15:06:00 -0000 =85Re-adding the list=85 On Oct 8, 2012, at 12:42 PM, olli hauer wrote: > ... >=20 >> You'll also get zero argument out of me that putting "Delete" on-screen = is not only to-be-avoided for the opposing situation (that some keyboards m= ay not have a "Delete" but instead "Backspace") but indeed "Delete" is wors= e because the implied connotation associated with the "Delete" key (_someon= e_ might be confused into thinking "Delete" will purge the menu from memory= ). >>=20 >> I will play with keycodes. >>=20 >> Just be aware that currently left arrow CANNOT work. That is a bad sugge= stion (read why below). >>=20 >> In Forth, I'm using the "key" primitive which -- rather unfortunately --= produces a zero for "left-arrow", "right-arrow", "up-arrow", "down-arrow",= "F1", "F2", "F3", "F4", "F5", "F6", "F7", "F8", "F9", and "F10" (note: it = doesn't catch "F11", "F12", "F13", "F14", "F15", or "F16"). >>=20 >> So all those key options are right-out when it comes to "using them inst= ead of Backspace" (I simply can't identify in the loader when those keys ar= e pressed). >>=20 >=20 > ... >=20 > will the space key work for a general back to or up one entry? > I suspect the space bar has the same keycode on all platforms (intel/appe= l/ppc/sparc ...) >=20 > Anyway nice work :) >=20 By golly, I think olli is on to something here! What does everybody think about space? I like it because it's a NICE BIG TARGET (and it's not used by anything els= e). --=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. From owner-freebsd-arch@FreeBSD.ORG Tue Oct 9 15:25:42 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 A3CB0CB; Tue, 9 Oct 2012 15:25:42 +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 625B18FC14; Tue, 9 Oct 2012 15:25:41 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa07.fnfis.com (8.14.4/8.14.4) with ESMTP id q99FODBG014901 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 9 Oct 2012 10:25:40 -0500 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.31) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 9 Oct 2012 10:25:25 -0500 Subject: Re: New Boot Loader Menu MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Devin Teske In-Reply-To: Date: Tue, 9 Oct 2012 08:25:19 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <515694A9-3D0F-4150-8865-F518072C5EC6@fisglobal.com> References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <5071D6B5.1010609@FreeBSD.org> <50726C73.10506@FreeBSD.org> <50732CB1.9080900@gmx.de> <71571815-CBF3-4B16-BA77-2828B8BA613C@fisglobal.com> To: Garrett Cooper 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-09_05:2012-10-09,2012-10-09,1970-01-01 signatures=0 Cc: Devin Teske , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 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: Tue, 09 Oct 2012 15:25:42 -0000 =85Re-adding the list=85 (good point) On Oct 9, 2012, at 8:15 AM, Garrett Cooper wrote: > On Tue, Oct 9, 2012 at 8:05 AM, Devin Teske w= rote: >> =85Re-adding the list=85 >>=20 >> On Oct 8, 2012, at 12:42 PM, olli hauer wrote: >>=20 >>> ... >>>=20 >>>> You'll also get zero argument out of me that putting "Delete" on-scree= n is not only to-be-avoided for the opposing situation (that some keyboards= may not have a "Delete" but instead "Backspace") but indeed "Delete" is wo= rse because the implied connotation associated with the "Delete" key (_some= one_ might be confused into thinking "Delete" will purge the menu from memo= ry). >>>>=20 >>>> I will play with keycodes. >>>>=20 >>>> Just be aware that currently left arrow CANNOT work. That is a bad sug= gestion (read why below). >>>>=20 >>>> In Forth, I'm using the "key" primitive which -- rather unfortunately = -- produces a zero for "left-arrow", "right-arrow", "up-arrow", "down-arrow= ", "F1", "F2", "F3", "F4", "F5", "F6", "F7", "F8", "F9", and "F10" (note: i= t doesn't catch "F11", "F12", "F13", "F14", "F15", or "F16"). >>>>=20 >>>> So all those key options are right-out when it comes to "using them in= stead of Backspace" (I simply can't identify in the loader when those keys = are pressed). >>>>=20 >>>=20 >>> ... >>>=20 >>> will the space key work for a general back to or up one entry? >>> I suspect the space bar has the same keycode on all platforms (intel/ap= pel/ppc/sparc ...) >>>=20 >>> Anyway nice work :) >>>=20 >>=20 >> By golly, I think olli is on to something here! >>=20 >> What does everybody think about space? >>=20 >> I like it because it's a NICE BIG TARGET (and it's not used by anything = else). >=20 > It was used once upon a time to pause the bootloader countdown=85 Well=85 that hasn't *really* been true since r222417 (16+ months ago). Ever since r222417, *any/all* keys will kill the countdown-to-boot. Since you mention it, I think it's worth mentioning that SPACE is still loo= king like a good choice=85 At the main-menu, space is not hooked into anything so it retains its legac= y of "press SPACE to stop the countdown" meanwhile, submenus are free to us= e SPACE because by the time they've reached *any* submenu, the countdown ha= s already been killed. --=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. From owner-freebsd-arch@FreeBSD.ORG Tue Oct 9 15:51:34 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 EAEC4847 for ; Tue, 9 Oct 2012 15:51:33 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 916CD8FC12 for ; Tue, 9 Oct 2012 15:51:33 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id l39so4926915qcs.13 for ; Tue, 09 Oct 2012 08:51:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=n2AcQ9vYHtgMv7OHLsuGrXinGkiFXjk943Cm1xzVilg=; b=NcPvvvDaieax/ojvaGvJEfJpWzzZwVQNeMWZHkkmkON3qFnfg4o5QQfLqKNIRmPYfu k/Zlf2aVE0PSvbvyozWQMLKsbmx4wSTUUgNIExV8u0840j63oMER9Z3ik0B9Trl95O2M xs4aIWc1cIOia2KFMXCcERCSYhRBLnJMy/TyWegV4klsBCWxI0eITr65pGFZmiPatTUT vq/Fi2uxs7wncqXgBkgWMaSLcooSYJmzOrkqqykhaICBQcFh1mk2EFtPq5tHlp4MTWRt 8yS29MBtm53f/LGYD9ddo7NMCJJg3SuhLxehqbXu+MEVKBIelTlEmyZt0WHKcauflTvb lFSw== Received: by 10.224.9.9 with SMTP id j9mr35559663qaj.32.1349797887413; Tue, 09 Oct 2012 08:51:27 -0700 (PDT) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id jw1sm20811323qeb.13.2012.10.09.08.51.22 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Oct 2012 08:51:25 -0700 (PDT) Sender: Warner Losh Subject: Re: New Boot Loader Menu Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warner Losh In-Reply-To: <71571815-CBF3-4B16-BA77-2828B8BA613C@fisglobal.com> Date: Tue, 9 Oct 2012 09:51:21 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <564537F0-8BB5-4036-8A81-0A3D0B179489@bsdimp.com> References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <5071D6B5.1010609@FreeBSD.org> <50726C73.10506@FreeBSD.org> <50732CB1.9080900@gmx.de> <71571815-CBF3-4B16-BA77-2828B8BA613C@fisglobal.com> To: Devin Teske X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmbRyxgv/vFt8iDp7zKncXJvOAKacDwIg8ZLXrabmjYekT3LCBFpUead1CwziqqAidly3g5 Cc: olli hauer , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 15:51:34 -0000 On Oct 9, 2012, at 9:05 AM, Devin Teske wrote: > =85Re-adding the list=85 >=20 > On Oct 8, 2012, at 12:42 PM, olli hauer wrote: >=20 >> ... >>=20 >>> You'll also get zero argument out of me that putting "Delete" = on-screen is not only to-be-avoided for the opposing situation (that = some keyboards may not have a "Delete" but instead "Backspace") but = indeed "Delete" is worse because the implied connotation associated with = the "Delete" key (_someone_ might be confused into thinking "Delete" = will purge the menu from memory). >>>=20 >>> I will play with keycodes. >>>=20 >>> Just be aware that currently left arrow CANNOT work. That is a bad = suggestion (read why below). >>>=20 >>> In Forth, I'm using the "key" primitive which -- rather = unfortunately -- produces a zero for "left-arrow", "right-arrow", = "up-arrow", "down-arrow", "F1", "F2", "F3", "F4", "F5", "F6", "F7", = "F8", "F9", and "F10" (note: it doesn't catch "F11", "F12", "F13", = "F14", "F15", or "F16"). >>>=20 >>> So all those key options are right-out when it comes to "using them = instead of Backspace" (I simply can't identify in the loader when those = keys are pressed). >>>=20 >>=20 >> ... >>=20 >> will the space key work for a general back to or up one entry? >> I suspect the space bar has the same keycode on all platforms = (intel/appel/ppc/sparc ...) >>=20 >> Anyway nice work :) >>=20 >=20 > By golly, I think olli is on to something here! >=20 > What does everybody think about space? >=20 > I like it because it's a NICE BIG TARGET (and it's not used by = anything else). space usually doesn't mean backup to most users. It usually means go = forward or select, so this is a poor match to what other systems do and = therefore to what one might expect joe-random-person to expect. Warner From owner-freebsd-arch@FreeBSD.ORG Tue Oct 9 15:53:20 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 4684E955 for ; Tue, 9 Oct 2012 15:53:20 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id DEC028FC14 for ; Tue, 9 Oct 2012 15:53:19 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id i29so3786572qaf.13 for ; Tue, 09 Oct 2012 08:53:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=OOr4KrKRNBYc0Sdb4yBjLxY+Nnf4btUGyur+Kli0M2A=; b=Vg/XxOmN+LHcDinTAiGxYw1MkRRRTKwpRAHCM4PXd8VyWfgy43JnOXdSnWczgn+mHY xCaL9xjUH8GX0mC00up7R3iG/1AuOi8IsPFHTAWGkztTjj+fg3aoTRf/id1S6S9r0KA9 /5CZJ/RBSl1tHZ+QMSKWwK4zbdS3FLiMBqUwiEKZ4E9ygbOw5wWG7R5OzuskYDTHEN8B u+9OFo8NgWLKk7ec3gm3L7FvEZONuYLoSAKf7dsemCcQKrqjLo1jYGanttjHsYU5PiuB yW+6MPcYOKM04HoKjqmXFQKZMZ1uYxVHcAjVUp3VcVZe5L/gWtrmIsRbqIj11LWDnUXi WRhg== Received: by 10.224.203.193 with SMTP id fj1mr35646782qab.13.1349797998969; Tue, 09 Oct 2012 08:53:18 -0700 (PDT) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id q7sm20813702qeo.6.2012.10.09.08.53.15 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Oct 2012 08:53:16 -0700 (PDT) Sender: Warner Losh Subject: Re: New Boot Loader Menu Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warner Losh In-Reply-To: <515694A9-3D0F-4150-8865-F518072C5EC6@fisglobal.com> Date: Tue, 9 Oct 2012 09:53:09 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <5071D6B5.1010609@FreeBSD.org> <50726C73.10506@FreeBSD.org> <50732CB1.9080900@gmx.de> <71571815-CBF3-4B16-BA77-2828B8BA613C@fisglobal.com> <515694A9-3D0F-4150-8865-F518072C5EC6@fisglobal.com> To: Devin Teske X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnkxIk0MmgRNBa36Yq5hngfO4QDupSPg6wiM8VhMNgqr3xs4Xd5ZiBG66FP6mmrELHjsn0N Cc: Garrett Cooper , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 15:53:20 -0000 On Oct 9, 2012, at 9:25 AM, Devin Teske wrote: > =85Re-adding the list=85 (good point) >=20 > On Oct 9, 2012, at 8:15 AM, Garrett Cooper wrote: >=20 >> On Tue, Oct 9, 2012 at 8:05 AM, Devin Teske = wrote: >>> =85Re-adding the list=85 >>>=20 >>> On Oct 8, 2012, at 12:42 PM, olli hauer wrote: >>>=20 >>>> ... >>>>=20 >>>>> You'll also get zero argument out of me that putting "Delete" = on-screen is not only to-be-avoided for the opposing situation (that = some keyboards may not have a "Delete" but instead "Backspace") but = indeed "Delete" is worse because the implied connotation associated with = the "Delete" key (_someone_ might be confused into thinking "Delete" = will purge the menu from memory). >>>>>=20 >>>>> I will play with keycodes. >>>>>=20 >>>>> Just be aware that currently left arrow CANNOT work. That is a bad = suggestion (read why below). >>>>>=20 >>>>> In Forth, I'm using the "key" primitive which -- rather = unfortunately -- produces a zero for "left-arrow", "right-arrow", = "up-arrow", "down-arrow", "F1", "F2", "F3", "F4", "F5", "F6", "F7", = "F8", "F9", and "F10" (note: it doesn't catch "F11", "F12", "F13", = "F14", "F15", or "F16"). >>>>>=20 >>>>> So all those key options are right-out when it comes to "using = them instead of Backspace" (I simply can't identify in the loader when = those keys are pressed). >>>>>=20 >>>>=20 >>>> ... >>>>=20 >>>> will the space key work for a general back to or up one entry? >>>> I suspect the space bar has the same keycode on all platforms = (intel/appel/ppc/sparc ...) >>>>=20 >>>> Anyway nice work :) >>>>=20 >>>=20 >>> By golly, I think olli is on to something here! >>>=20 >>> What does everybody think about space? >>>=20 >>> I like it because it's a NICE BIG TARGET (and it's not used by = anything else). >>=20 >> It was used once upon a time to pause the bootloader countdown=85 >=20 > Well=85 that hasn't *really* been true since r222417 (16+ months ago). >=20 > Ever since r222417, *any/all* keys will kill the countdown-to-boot. >=20 > Since you mention it, I think it's worth mentioning that SPACE is = still looking like a good choice=85 >=20 > At the main-menu, space is not hooked into anything so it retains its = legacy of "press SPACE to stop the countdown" meanwhile, submenus are = free to use SPACE because by the time they've reached *any* submenu, the = countdown has already been killed. This will be too confusing for users. Space usually means 'select the = current menu item' along with Return. It doesn't mean in any system = I've ever used 'go back' (with the exception of space selecting a drawn = button that says back). Warner From owner-freebsd-arch@FreeBSD.ORG Tue Oct 9 16:07:28 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 D1316277; Tue, 9 Oct 2012 16:07:28 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 5D7B88FC18; Tue, 9 Oct 2012 16:07:28 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id q99G7R3A096682; Tue, 9 Oct 2012 10:07:27 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q99G7PUg080561; Tue, 9 Oct 2012 10:07:25 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: New Boot Loader Menu From: Ian Lepore To: Warner Losh In-Reply-To: References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <5071D6B5.1010609@FreeBSD.org> <50726C73.10506@FreeBSD.org> <50732CB1.9080900@gmx.de> <71571815-CBF3-4B16-BA77-2828B8BA613C@fisglobal.com> <515694A9-3D0F-4150-8865-F518072C5EC6@fisglobal.com> Content-Type: text/plain; charset="windows-1251" Date: Tue, 09 Oct 2012 10:07:25 -0600 Message-ID: <1349798845.1123.10.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: Garrett Cooper , Devin Teske , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 16:07:29 -0000 On Tue, 2012-10-09 at 09:53 -0600, Warner Losh wrote: > On Oct 9, 2012, at 9:25 AM, Devin Teske wrote: > > > …Re-adding the list… (good point) > > > > On Oct 9, 2012, at 8:15 AM, Garrett Cooper wrote: > > > >> On Tue, Oct 9, 2012 at 8:05 AM, Devin Teske wrote: > >>> …Re-adding the list… > >>> > >>> On Oct 8, 2012, at 12:42 PM, olli hauer wrote: > >>> > >>>> ... > >>>> > >>>>> You'll also get zero argument out of me that putting "Delete" on-screen is not only to-be-avoided for the opposing situation (that some keyboards may not have a "Delete" but instead "Backspace") but indeed "Delete" is worse because the implied connotation associated with the "Delete" key (_someone_ might be confused into thinking "Delete" will purge the menu from memory). > >>>>> > >>>>> I will play with keycodes. > >>>>> > >>>>> Just be aware that currently left arrow CANNOT work. That is a bad suggestion (read why below). > >>>>> > >>>>> In Forth, I'm using the "key" primitive which -- rather unfortunately -- produces a zero for "left-arrow", "right-arrow", "up-arrow", "down-arrow", "F1", "F2", "F3", "F4", "F5", "F6", "F7", "F8", "F9", and "F10" (note: it doesn't catch "F11", "F12", "F13", "F14", "F15", or "F16"). > >>>>> > >>>>> So all those key options are right-out when it comes to "using them instead of Backspace" (I simply can't identify in the loader when those keys are pressed). > >>>>> > >>>> > >>>> ... > >>>> > >>>> will the space key work for a general back to or up one entry? > >>>> I suspect the space bar has the same keycode on all platforms (intel/appel/ppc/sparc ...) > >>>> > >>>> Anyway nice work :) > >>>> > >>> > >>> By golly, I think olli is on to something here! > >>> > >>> What does everybody think about space? > >>> > >>> I like it because it's a NICE BIG TARGET (and it's not used by anything else). > >> > >> It was used once upon a time to pause the bootloader countdown… > > > > Well… that hasn't *really* been true since r222417 (16+ months ago). > > > > Ever since r222417, *any/all* keys will kill the countdown-to-boot. > > > > Since you mention it, I think it's worth mentioning that SPACE is still looking like a good choice… > > > > At the main-menu, space is not hooked into anything so it retains its legacy of "press SPACE to stop the countdown" meanwhile, submenus are free to use SPACE because by the time they've reached *any* submenu, the countdown has already been killed. > > This will be too confusing for users. Space usually means 'select the current menu item' along with Return. It doesn't mean in any system I've ever used 'go back' (with the exception of space selecting a drawn button that says back). I agree, using space for "go back" would be a POLA violation. How about Escape, that often means go-back in a UI (common in BIOS config screens), and I didn't see it on the list of forbidden keys. (Not that I'm emotionally invested in this stuff at all. The only boot-menu feature that I would fight hard for is the one that I've used for years: beastie_disable=YES.) -- Ian From owner-freebsd-arch@FreeBSD.ORG Tue Oct 9 16:24:52 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 7BD46A66; Tue, 9 Oct 2012 16:24:52 +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 328008FC08; Tue, 9 Oct 2012 16:24:51 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa01.fnfis.com (8.14.4/8.14.4) with ESMTP id q99GOkSD013514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 9 Oct 2012 11:24:47 -0500 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.15) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 9 Oct 2012 11:24:44 -0500 Subject: Re: New Boot Loader Menu MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1251" From: Devin Teske In-Reply-To: <1349798845.1123.10.camel@revolution.hippie.lan> Date: Tue, 9 Oct 2012 09:24:37 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <6389190E-16B1-4B32-937D-677B966EB7AA@fisglobal.com> References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <5071D6B5.1010609@FreeBSD.org> <50726C73.10506@FreeBSD.org> <50732CB1.9080900@gmx.de> <71571815-CBF3-4B16-BA77-2828B8BA613C@fisglobal.com> <515694A9-3D0F-4150-8865-F518072C5EC6@fisglobal.com> <1349798845.1123.10.camel@revolution.hippie.lan> To: Ian Lepore 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-09_05:2012-10-09,2012-10-09,1970-01-01 signatures=0 Cc: Garrett Cooper , Devin Teske , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 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: Tue, 09 Oct 2012 16:24:52 -0000 On Oct 9, 2012, at 9:07 AM, Ian Lepore wrote: > On Tue, 2012-10-09 at 09:53 -0600, Warner Losh wrote: >> On Oct 9, 2012, at 9:25 AM, Devin Teske wrote: >>=20 >>> =85Re-adding the list=85 (good point) >>>=20 >>> On Oct 9, 2012, at 8:15 AM, Garrett Cooper wrote: >>>=20 >>>> On Tue, Oct 9, 2012 at 8:05 AM, Devin Teske wrote: >>>>> =85Re-adding the list=85 >>>>>=20 >>>>> On Oct 8, 2012, at 12:42 PM, olli hauer wrote: >>>>>=20 >>>>>> ... >>>>>>=20 >>>>>>> You'll also get zero argument out of me that putting "Delete" on-sc= reen is not only to-be-avoided for the opposing situation (that some keyboa= rds may not have a "Delete" but instead "Backspace") but indeed "Delete" is= worse because the implied connotation associated with the "Delete" key (_s= omeone_ might be confused into thinking "Delete" will purge the menu from m= emory). >>>>>>>=20 >>>>>>> I will play with keycodes. >>>>>>>=20 >>>>>>> Just be aware that currently left arrow CANNOT work. That is a bad = suggestion (read why below). >>>>>>>=20 >>>>>>> In Forth, I'm using the "key" primitive which -- rather unfortunate= ly -- produces a zero for "left-arrow", "right-arrow", "up-arrow", "down-ar= row", "F1", "F2", "F3", "F4", "F5", "F6", "F7", "F8", "F9", and "F10" (note= : it doesn't catch "F11", "F12", "F13", "F14", "F15", or "F16"). >>>>>>>=20 >>>>>>> So all those key options are right-out when it comes to "using them= instead of Backspace" (I simply can't identify in the loader when those ke= ys are pressed). >>>>>>>=20 >>>>>>=20 >>>>>> ... >>>>>>=20 >>>>>> will the space key work for a general back to or up one entry? >>>>>> I suspect the space bar has the same keycode on all platforms (intel= /appel/ppc/sparc ...) >>>>>>=20 >>>>>> Anyway nice work :) >>>>>>=20 >>>>>=20 >>>>> By golly, I think olli is on to something here! >>>>>=20 >>>>> What does everybody think about space? >>>>>=20 >>>>> I like it because it's a NICE BIG TARGET (and it's not used by anythi= ng else). >>>>=20 >>>> It was used once upon a time to pause the bootloader countdown=85 >>>=20 >>> Well=85 that hasn't *really* been true since r222417 (16+ months ago). >>>=20 >>> Ever since r222417, *any/all* keys will kill the countdown-to-boot. >>>=20 >>> Since you mention it, I think it's worth mentioning that SPACE is still= looking like a good choice=85 >>>=20 >>> At the main-menu, space is not hooked into anything so it retains its l= egacy of "press SPACE to stop the countdown" meanwhile, submenus are free t= o use SPACE because by the time they've reached *any* submenu, the countdow= n has already been killed. >>=20 >> This will be too confusing for users. Space usually means 'select the c= urrent menu item' along with Return. It doesn't mean in any system I've ev= er used 'go back' (with the exception of space selecting a drawn button tha= t says back). >=20 > I agree, using space for "go back" would be a POLA violation.=20=20 >=20 > How about Escape, that often means go-back in a UI (common in BIOS > config screens), and I didn't see it on the list of forbidden keys. >=20 The main-menu uses it to drop the user to the interactive "ok>" prompt. --=20 Devin > (Not that I'm emotionally invested in this stuff at all. The only > boot-menu feature that I would fight hard for is the one that I've used > for years: beastie_disable=3DYES.) >=20 > -- Ian >=20 >=20 _____________ 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. From owner-freebsd-arch@FreeBSD.ORG Tue Oct 9 16:30:28 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 061C6CCC; Tue, 9 Oct 2012 16:30:28 +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 BA0818FC12; Tue, 9 Oct 2012 16:30:27 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa04.fnfis.com (8.14.4/8.14.4) with ESMTP id q99GU7rJ026370 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 9 Oct 2012 11:30:25 -0500 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.31) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 9 Oct 2012 11:30:19 -0500 Subject: Re: New Boot Loader Menu MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Devin Teske In-Reply-To: <564537F0-8BB5-4036-8A81-0A3D0B179489@bsdimp.com> Date: Tue, 9 Oct 2012 09:30:12 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <4EA5C2FF-ABFA-4BA6-95CA-8E722F91999E@fisglobal.com> References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <5071D6B5.1010609@FreeBSD.org> <50726C73.10506@FreeBSD.org> <50732CB1.9080900@gmx.de> <71571815-CBF3-4B16-BA77-2828B8BA613C@fisglobal.com> <564537F0-8BB5-4036-8A81-0A3D0B179489@bsdimp.com> To: Warner Losh 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-09_05:2012-10-09,2012-10-09,1970-01-01 signatures=0 Cc: olli hauer , Devin Teske , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 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: Tue, 09 Oct 2012 16:30:28 -0000 On Oct 9, 2012, at 8:51 AM, Warner Losh wrote: >=20 > On Oct 9, 2012, at 9:05 AM, Devin Teske wrote: >=20 >> =85Re-adding the list=85 >>=20 >> On Oct 8, 2012, at 12:42 PM, olli hauer wrote: >>=20 >>> ... >>>=20 >>>> You'll also get zero argument out of me that putting "Delete" on-scree= n is not only to-be-avoided for the opposing situation (that some keyboards= may not have a "Delete" but instead "Backspace") but indeed "Delete" is wo= rse because the implied connotation associated with the "Delete" key (_some= one_ might be confused into thinking "Delete" will purge the menu from memo= ry). >>>>=20 >>>> I will play with keycodes. >>>>=20 >>>> Just be aware that currently left arrow CANNOT work. That is a bad sug= gestion (read why below). >>>>=20 >>>> In Forth, I'm using the "key" primitive which -- rather unfortunately = -- produces a zero for "left-arrow", "right-arrow", "up-arrow", "down-arrow= ", "F1", "F2", "F3", "F4", "F5", "F6", "F7", "F8", "F9", and "F10" (note: i= t doesn't catch "F11", "F12", "F13", "F14", "F15", or "F16"). >>>>=20 >>>> So all those key options are right-out when it comes to "using them in= stead of Backspace" (I simply can't identify in the loader when those keys = are pressed). >>>>=20 >>>=20 >>> ... >>>=20 >>> will the space key work for a general back to or up one entry? >>> I suspect the space bar has the same keycode on all platforms (intel/ap= pel/ppc/sparc ...) >>>=20 >>> Anyway nice work :) >>>=20 >>=20 >> By golly, I think olli is on to something here! >>=20 >> What does everybody think about space? >>=20 >> I like it because it's a NICE BIG TARGET (and it's not used by anything = else). >=20 > space usually doesn't mean backup to most users. It usually means go for= ward or select, so this is a poor match to what other systems do and theref= ore to what one might expect joe-random-person to expect. >=20 Ok, space is out. *thinks* Ok, "b for back" is out because "b" on the main menu is boot (even if not h= ighlighted -- see menu.rc keycode[1] and corresponding ascii(7), decimal 'b= ' is 98). Ok, space, any F# keys, any arrow keys, and backspace are also out. Hmmm=85 I'm looking at my keyboard and nothing really sticks out. 'M' perhaps for "Back to [M]ain Menu" --=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. From owner-freebsd-arch@FreeBSD.ORG Tue Oct 9 16:38:35 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 A7F34FCF; Tue, 9 Oct 2012 16:38:35 +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 6582A8FC0A; Tue, 9 Oct 2012 16:38:35 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa01.fnfis.com (8.14.4/8.14.4) with ESMTP id q99GcVTx032192 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 9 Oct 2012 11:38:31 -0500 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.16) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 9 Oct 2012 11:38:31 -0500 Subject: Re: New Boot Loader Menu MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Devin Teske In-Reply-To: <4EA5C2FF-ABFA-4BA6-95CA-8E722F91999E@fisglobal.com> Date: Tue, 9 Oct 2012 09:38:28 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <5071D6B5.1010609@FreeBSD.org> <50726C73.10506@FreeBSD.org> <50732CB1.9080900@gmx.de> <71571815-CBF3-4B16-BA77-2828B8BA613C@fisglobal.com> <564537F0-8BB5-4036-8A81-0A3D0B179489@bsdimp.com> <4EA5C2FF-ABFA-4BA6-95CA-8E722F91999E@fisglobal.com> To: Devin Teske 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-09_05:2012-10-09,2012-10-09,1970-01-01 signatures=0 Cc: olli hauer , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 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: Tue, 09 Oct 2012 16:38:35 -0000 On Oct 9, 2012, at 9:30 AM, Devin Teske wrote: >=20 > On Oct 9, 2012, at 8:51 AM, Warner Losh wrote: >=20 >>=20 >> On Oct 9, 2012, at 9:05 AM, Devin Teske wrote: >>=20 >>> =85Re-adding the list=85 >>>=20 >>> On Oct 8, 2012, at 12:42 PM, olli hauer wrote: >>>=20 >>>> ... >>>>=20 >>>>> You'll also get zero argument out of me that putting "Delete" on-scre= en is not only to-be-avoided for the opposing situation (that some keyboard= s may not have a "Delete" but instead "Backspace") but indeed "Delete" is w= orse because the implied connotation associated with the "Delete" key (_som= eone_ might be confused into thinking "Delete" will purge the menu from mem= ory). >>>>>=20 >>>>> I will play with keycodes. >>>>>=20 >>>>> Just be aware that currently left arrow CANNOT work. That is a bad su= ggestion (read why below). >>>>>=20 >>>>> In Forth, I'm using the "key" primitive which -- rather unfortunately= -- produces a zero for "left-arrow", "right-arrow", "up-arrow", "down-arro= w", "F1", "F2", "F3", "F4", "F5", "F6", "F7", "F8", "F9", and "F10" (note: = it doesn't catch "F11", "F12", "F13", "F14", "F15", or "F16"). >>>>>=20 >>>>> So all those key options are right-out when it comes to "using them i= nstead of Backspace" (I simply can't identify in the loader when those keys= are pressed). >>>>>=20 >>>>=20 >>>> ... >>>>=20 >>>> will the space key work for a general back to or up one entry? >>>> I suspect the space bar has the same keycode on all platforms (intel/a= ppel/ppc/sparc ...) >>>>=20 >>>> Anyway nice work :) >>>>=20 >>>=20 >>> By golly, I think olli is on to something here! >>>=20 >>> What does everybody think about space? >>>=20 >>> I like it because it's a NICE BIG TARGET (and it's not used by anything= else). >>=20 >> space usually doesn't mean backup to most users. It usually means go fo= rward or select, so this is a poor match to what other systems do and there= fore to what one might expect joe-random-person to expect. >>=20 >=20 > Ok, space is out. >=20 > *thinks* >=20 > Ok, "b for back" is out because "b" on the main menu is boot (even if not= highlighted -- see menu.rc keycode[1] and corresponding ascii(7), decimal = 'b' is 98). >=20 > Ok, space, any F# keys, any arrow keys, and backspace are also out. >=20 > Hmmm=85 >=20 > I'm looking at my keyboard and nothing really sticks out. >=20 > 'M' perhaps for "Back to [M]ain Menu" >=20 There is of course the obvious alternative=85 we have no keycode and the us= er just has to press "1" (that's always been an option). --=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. From owner-freebsd-arch@FreeBSD.ORG Tue Oct 9 18:25:48 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 D05EBAD2; Tue, 9 Oct 2012 18:25:48 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A1F798FC20; Tue, 9 Oct 2012 18:25:48 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F35A6B963; Tue, 9 Oct 2012 14:25:47 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org, Devin Teske Subject: Re: New Boot Loader Menu Date: Tue, 9 Oct 2012 14:18:50 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <515694A9-3D0F-4150-8865-F518072C5EC6@fisglobal.com> In-Reply-To: <515694A9-3D0F-4150-8865-F518072C5EC6@fisglobal.com> MIME-Version: 1.0 Message-Id: <201210091418.50649.jhb@freebsd.org> Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 09 Oct 2012 14:25:48 -0400 (EDT) Cc: Garrett Cooper X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 18:25:48 -0000 On Tuesday, October 09, 2012 11:25:19 am Devin Teske wrote: > =85Re-adding the list=85 (good point) >=20 > On Oct 9, 2012, at 8:15 AM, Garrett Cooper wrote: >=20 > > On Tue, Oct 9, 2012 at 8:05 AM, Devin Teske = wrote: > >> =85Re-adding the list=85 > >>=20 > >> On Oct 8, 2012, at 12:42 PM, olli hauer wrote: > >>=20 > >>> ... > >>>=20 > >>>> You'll also get zero argument out of me that putting "Delete" on-scr= een=20 is not only to-be-avoided for the opposing situation (that some keyboards m= ay=20 not have a "Delete" but instead "Backspace") but indeed "Delete" is worse=20 because the implied connotation associated with the "Delete" key (_someone_= =20 might be confused into thinking "Delete" will purge the menu from memory). > >>>>=20 > >>>> I will play with keycodes. > >>>>=20 > >>>> Just be aware that currently left arrow CANNOT work. That is a bad=20 suggestion (read why below). > >>>>=20 > >>>> In Forth, I'm using the "key" primitive which -- rather unfortunatel= y=20 =2D- produces a zero for "left-arrow", "right-arrow", "up-arrow", "down-arr= ow",=20 "F1", "F2", "F3", "F4", "F5", "F6", "F7", "F8", "F9", and "F10" (note: it=20 doesn't catch "F11", "F12", "F13", "F14", "F15", or "F16"). > >>>>=20 > >>>> So all those key options are right-out when it comes to "using them= =20 instead of Backspace" (I simply can't identify in the loader when those key= s=20 are pressed). > >>>>=20 > >>>=20 > >>> ... > >>>=20 > >>> will the space key work for a general back to or up one entry? > >>> I suspect the space bar has the same keycode on all platforms=20 (intel/appel/ppc/sparc ...) > >>>=20 > >>> Anyway nice work :) > >>>=20 > >>=20 > >> By golly, I think olli is on to something here! > >>=20 > >> What does everybody think about space? > >>=20 > >> I like it because it's a NICE BIG TARGET (and it's not used by anythin= g else). > >=20 > > It was used once upon a time to pause the bootloader countdown=85 >=20 > Well=85 that hasn't *really* been true since r222417 (16+ months ago). Yes, you completely destroyed POLA for users used to hitting various keys to catch the boot loader before it passed by over remote KVMs. Please don't keep moving the goal posts. The only reason my co-workers aren't screaming= =20 loudly about this to date is that we still use 8.x. Users get these key=20 bindings ingrained and we shouldn't change them lightly. That is really my only comment for this thread. It seems you are intent on breaking POLA for little to no gain and have no compunction about doing so which is a shame. =2D-=20 John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Oct 9 18:41:49 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 031FD7DA; Tue, 9 Oct 2012 18:41:49 +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 813048FC12; Tue, 9 Oct 2012 18:41:48 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa06.fnfis.com (8.14.4/8.14.4) with ESMTP id q99IffwL018135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 9 Oct 2012 13:41:41 -0500 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.31) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 9 Oct 2012 13:41:40 -0500 Subject: Re: New Boot Loader Menu MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Devin Teske In-Reply-To: <201210091418.50649.jhb@freebsd.org> Date: Tue, 9 Oct 2012 11:41:29 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <5D193023-90EC-4E8D-9FB9-D8D6468DF6A7@fisglobal.com> References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <515694A9-3D0F-4150-8865-F518072C5EC6@fisglobal.com> <201210091418.50649.jhb@freebsd.org> To: John Baldwin 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-09_05:2012-10-09,2012-10-09,1970-01-01 signatures=0 Cc: Garrett Cooper , Devin Teske , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 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: Tue, 09 Oct 2012 18:41:49 -0000 On Oct 9, 2012, at 11:18 AM, John Baldwin wrote: > On Tuesday, October 09, 2012 11:25:19 am Devin Teske wrote: >> =85Re-adding the list=85 (good point) >>=20 >> On Oct 9, 2012, at 8:15 AM, Garrett Cooper wrote: >>=20 >>> On Tue, Oct 9, 2012 at 8:05 AM, Devin Teske = wrote: >>>> =85Re-adding the list=85 >>>>=20 >>>> On Oct 8, 2012, at 12:42 PM, olli hauer wrote: >>>>=20 >>>>> ... >>>>>=20 >>>>>> You'll also get zero argument out of me that putting "Delete" on-scr= een=20 > is not only to-be-avoided for the opposing situation (that some keyboards= may=20 > not have a "Delete" but instead "Backspace") but indeed "Delete" is worse= =20 > because the implied connotation associated with the "Delete" key (_someon= e_=20 > might be confused into thinking "Delete" will purge the menu from memory). >>>>>>=20 >>>>>> I will play with keycodes. >>>>>>=20 >>>>>> Just be aware that currently left arrow CANNOT work. That is a bad= =20 > suggestion (read why below). >>>>>>=20 >>>>>> In Forth, I'm using the "key" primitive which -- rather unfortunatel= y=20 > -- produces a zero for "left-arrow", "right-arrow", "up-arrow", "down-arr= ow",=20 > "F1", "F2", "F3", "F4", "F5", "F6", "F7", "F8", "F9", and "F10" (note: it= =20 > doesn't catch "F11", "F12", "F13", "F14", "F15", or "F16"). >>>>>>=20 >>>>>> So all those key options are right-out when it comes to "using them= =20 > instead of Backspace" (I simply can't identify in the loader when those k= eys=20 > are pressed). >>>>>>=20 >>>>>=20 >>>>> ... >>>>>=20 >>>>> will the space key work for a general back to or up one entry? >>>>> I suspect the space bar has the same keycode on all platforms=20 > (intel/appel/ppc/sparc ...) >>>>>=20 >>>>> Anyway nice work :) >>>>>=20 >>>>=20 >>>> By golly, I think olli is on to something here! >>>>=20 >>>> What does everybody think about space? >>>>=20 >>>> I like it because it's a NICE BIG TARGET (and it's not used by anythin= g else). >>>=20 >>> It was used once upon a time to pause the bootloader countdown=85 >>=20 >> Well=85 that hasn't *really* been true since r222417 (16+ months ago). >=20 > Yes, you completely destroyed POLA for users used to hitting various keys > to catch the boot loader before it passed by over remote KVMs. Wait, what? I did no such thing. If you had users mashing random keys during the menu, the old functionality= was to keep the timer rolling while they mashed away. After r222417, you could still mash away=85 except the timer stopped. I believe in this instance, I improved an already questionable situation. Q= uestionable because "why were they mashing?" -- the likely answer being "th= ey wanted to either wake things up or they wanted to access the menu" -- in= which case I think the old functionality of continuing the timer until ONL= Y space was it is never what was desired. Is there really a drove of like-minded individuals that _want_ the timer to= keep rolling when someone is mashing keys? ASIDE: Let's ignore the obvious that even in FreeBSD-6, mashing keys could = have led to unknown results as hitting 's' would lead to immediate single-u= ser boot. > Please don't > keep moving the goal posts. Alexander Leidinger recently proposed moving "Single User" back to being an= action item (opposed to being a stateful boolean menuitem). This would ret= urn the functionality of "press s to boot SUM" (versus "press s then Enter = to boot SUM" which changed in r222417). It sounds like you might be a proponent of this. > The only reason my co-workers aren't screaming=20 > loudly about this to date is that we still use 8.x. Well, I advocate them to voice their opinions (tho shouting isn't advocated= ). > Users get these key=20 > bindings ingrained and we shouldn't change them lightly. >=20 See previous discussion. What key binding did they memorize that I broke? > That is really my only comment for this thread. It seems you are intent = on > breaking POLA for little to no gain and have no compunction about doing so > which is a shame. >=20 Absolutely no comment. --=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. From owner-freebsd-arch@FreeBSD.ORG Tue Oct 9 19:04:23 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 CB318CF; Tue, 9 Oct 2012 19:04:23 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 856108FC0A; Tue, 9 Oct 2012 19:04:23 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E2E22B91E; Tue, 9 Oct 2012 15:04:22 -0400 (EDT) From: John Baldwin To: Devin Teske Subject: Re: New Boot Loader Menu Date: Tue, 9 Oct 2012 15:03:17 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <201210091418.50649.jhb@freebsd.org> <5D193023-90EC-4E8D-9FB9-D8D6468DF6A7@fisglobal.com> In-Reply-To: <5D193023-90EC-4E8D-9FB9-D8D6468DF6A7@fisglobal.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Message-Id: <201210091503.17909.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 09 Oct 2012 15:04:23 -0400 (EDT) Cc: Garrett Cooper , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 19:04:23 -0000 On Tuesday, October 09, 2012 2:41:29 pm Devin Teske wrote: >=20 > On Oct 9, 2012, at 11:18 AM, John Baldwin wrote: >=20 > > On Tuesday, October 09, 2012 11:25:19 am Devin Teske wrote: > >> =85Re-adding the list=85 (good point) > >>=20 > >> On Oct 9, 2012, at 8:15 AM, Garrett Cooper wrote: > >>=20 > >>> On Tue, Oct 9, 2012 at 8:05 AM, Devin Teske =20 wrote: > >>>> =85Re-adding the list=85 > >>>>=20 > >>>> On Oct 8, 2012, at 12:42 PM, olli hauer wrote: > >>>>=20 > >>>>> ... > >>>>>=20 > >>>>>> You'll also get zero argument out of me that putting "Delete" on- screen=20 > > is not only to-be-avoided for the opposing situation (that some keyboar= ds=20 may=20 > > not have a "Delete" but instead "Backspace") but indeed "Delete" is wor= se=20 > > because the implied connotation associated with the "Delete" key=20 (_someone_=20 > > might be confused into thinking "Delete" will purge the menu from memor= y). > >>>>>>=20 > >>>>>> I will play with keycodes. > >>>>>>=20 > >>>>>> Just be aware that currently left arrow CANNOT work. That is a bad= =20 > > suggestion (read why below). > >>>>>>=20 > >>>>>> In Forth, I'm using the "key" primitive which -- rather unfortunat= ely=20 > > -- produces a zero for "left-arrow", "right-arrow", "up-arrow", "down- arrow",=20 > > "F1", "F2", "F3", "F4", "F5", "F6", "F7", "F8", "F9", and "F10" (note: = it=20 > > doesn't catch "F11", "F12", "F13", "F14", "F15", or "F16"). > >>>>>>=20 > >>>>>> So all those key options are right-out when it comes to "using the= m=20 > > instead of Backspace" (I simply can't identify in the loader when those= =20 keys=20 > > are pressed). > >>>>>>=20 > >>>>>=20 > >>>>> ... > >>>>>=20 > >>>>> will the space key work for a general back to or up one entry? > >>>>> I suspect the space bar has the same keycode on all platforms=20 > > (intel/appel/ppc/sparc ...) > >>>>>=20 > >>>>> Anyway nice work :) > >>>>>=20 > >>>>=20 > >>>> By golly, I think olli is on to something here! > >>>>=20 > >>>> What does everybody think about space? > >>>>=20 > >>>> I like it because it's a NICE BIG TARGET (and it's not used by anyth= ing=20 else). > >>>=20 > >>> It was used once upon a time to pause the bootloader countdown=85 > >>=20 > >> Well=85 that hasn't *really* been true since r222417 (16+ months ago). > >=20 > > Yes, you completely destroyed POLA for users used to hitting various ke= ys > > to catch the boot loader before it passed by over remote KVMs. >=20 > Wait, what? >=20 > I did no such thing. >=20 > If you had users mashing random keys during the menu, the old functionali= ty=20 was to keep the timer rolling while they mashed away. No, not random keys. Keys like '6' to escape to the loader prompt or '4' t= o=20 boot into single user. It's water under the bridge as far as the new menu in 9.0 (and I thought th= at=20 in that instance renumbering everything might be worth it to make the keys= =20 more logical as a one-time hit), but gratuitously changing the mappings of= =20 what specific keys mean is not helpful to users, and based on your reply, y= ou=20 don't get that at all. It is the lack of empathy for other use cases that= =20 most worries me. :( =2D-=20 John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Oct 9 19:15:07 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 655474A3; Tue, 9 Oct 2012 19:15:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 372008FC08; Tue, 9 Oct 2012 19:15:07 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9A44EB918; Tue, 9 Oct 2012 15:15:06 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: New Boot Loader Menu Date: Tue, 9 Oct 2012 15:15:06 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <5D193023-90EC-4E8D-9FB9-D8D6468DF6A7@fisglobal.com> <201210091503.17909.jhb@freebsd.org> In-Reply-To: <201210091503.17909.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Message-Id: <201210091515.06082.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 09 Oct 2012 15:15:06 -0400 (EDT) Cc: Garrett Cooper , Devin Teske X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 19:15:07 -0000 On Tuesday, October 09, 2012 3:03:17 pm John Baldwin wrote: > On Tuesday, October 09, 2012 2:41:29 pm Devin Teske wrote: > >=20 > > On Oct 9, 2012, at 11:18 AM, John Baldwin wrote: > >=20 > > > On Tuesday, October 09, 2012 11:25:19 am Devin Teske wrote: > > >> =85Re-adding the list=85 (good point) > > >>=20 > > >> On Oct 9, 2012, at 8:15 AM, Garrett Cooper wrote: > > >>=20 > > >>> On Tue, Oct 9, 2012 at 8:05 AM, Devin Teske =20 > wrote: > > >>>> =85Re-adding the list=85 > > >>>>=20 > > >>>> On Oct 8, 2012, at 12:42 PM, olli hauer wrote: > > >>>>=20 > > >>>>> ... > > >>>>>=20 > > >>>>>> You'll also get zero argument out of me that putting "Delete" on- > screen=20 > > > is not only to-be-avoided for the opposing situation (that some keybo= ards=20 > may=20 > > > not have a "Delete" but instead "Backspace") but indeed "Delete" is w= orse=20 > > > because the implied connotation associated with the "Delete" key=20 > (_someone_=20 > > > might be confused into thinking "Delete" will purge the menu from mem= ory). > > >>>>>>=20 > > >>>>>> I will play with keycodes. > > >>>>>>=20 > > >>>>>> Just be aware that currently left arrow CANNOT work. That is a b= ad=20 > > > suggestion (read why below). > > >>>>>>=20 > > >>>>>> In Forth, I'm using the "key" primitive which -- rather unfortun= ately=20 > > > -- produces a zero for "left-arrow", "right-arrow", "up-arrow", "down- > arrow",=20 > > > "F1", "F2", "F3", "F4", "F5", "F6", "F7", "F8", "F9", and "F10" (note= : it=20 > > > doesn't catch "F11", "F12", "F13", "F14", "F15", or "F16"). > > >>>>>>=20 > > >>>>>> So all those key options are right-out when it comes to "using t= hem=20 > > > instead of Backspace" (I simply can't identify in the loader when tho= se=20 > keys=20 > > > are pressed). > > >>>>>>=20 > > >>>>>=20 > > >>>>> ... > > >>>>>=20 > > >>>>> will the space key work for a general back to or up one entry? > > >>>>> I suspect the space bar has the same keycode on all platforms=20 > > > (intel/appel/ppc/sparc ...) > > >>>>>=20 > > >>>>> Anyway nice work :) > > >>>>>=20 > > >>>>=20 > > >>>> By golly, I think olli is on to something here! > > >>>>=20 > > >>>> What does everybody think about space? > > >>>>=20 > > >>>> I like it because it's a NICE BIG TARGET (and it's not used by any= thing=20 > else). > > >>>=20 > > >>> It was used once upon a time to pause the bootloader countdown=85 > > >>=20 > > >> Well=85 that hasn't *really* been true since r222417 (16+ months ago= ). > > >=20 > > > Yes, you completely destroyed POLA for users used to hitting various = keys > > > to catch the boot loader before it passed by over remote KVMs. > >=20 > > Wait, what? > >=20 > > I did no such thing. > >=20 > > If you had users mashing random keys during the menu, the old functiona= lity=20 > was to keep the timer rolling while they mashed away. >=20 > No, not random keys. Keys like '6' to escape to the loader prompt or '4'= to=20 > boot into single user. >=20 > It's water under the bridge as far as the new menu in 9.0 (and I thought = that=20 > in that instance renumbering everything might be worth it to make the key= s=20 > more logical as a one-time hit), but gratuitously changing the mappings o= f=20 > what specific keys mean is not helpful to users, and based on your reply,= you=20 > don't get that at all. It is the lack of empathy for other use cases tha= t=20 > most worries me. :( =46WIW, I hadn't realized / remembered correctly that someone else changed = the order in 9.0 and that your original menu changes preserved the bindings. I would just like to avoid changing existing key bindings as much as possible going forward. =2D-=20 John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Oct 9 20:03:34 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 A6BC1B00; Tue, 9 Oct 2012 20:03:34 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 33F768FC08; Tue, 9 Oct 2012 20:03:33 +0000 (UTC) Received: from outgoing.leidinger.net (p5DD4506C.dip.t-dialin.net [93.212.80.108]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id ADECF844006; Tue, 9 Oct 2012 22:03:29 +0200 (CEST) Received: from unknown (IO.Leidinger.net [192.168.1.12]) by outgoing.leidinger.net (Postfix) with ESMTPS id 406C72200; Tue, 9 Oct 2012 22:03:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1349813007; bh=qHnZVwAw5MdLRhWrAtG22xZ27QkO9nz6P2P8HoPob3c=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=UU1p65Lhw++dj4PdgQDEu7/HcWRg1NuNRW15MeD4sdd46+k1FLvI9vyRQUOwPc6DU nuEiE5OzK+1QZO3jEwjcRL0WWxBHM0I7B/247/7M7AZFvNEv3j6pLPNopxiaJufYIT 8rBL1DHvT/zzepcxLyL3aKB+oW0lthaG0ChtUnwMdUp6+Z53xqJMBBS9iSbevs+m4p VSxwaKGwQq5oOxIhN5Qd+xcFiyVBhyz7usWm/61r0gGXk/Mb49dkaDAXIpxRYpWEiX NMwsWTbYFD7nuXrDACwp+YPB4E4P0Qhz8kCMm+2uA+UAq2R2HfhuCAEmRWFPOsQEUa ht8Gyegq9yZ/Q== Date: Tue, 9 Oct 2012 22:03:25 +0200 From: Alexander Leidinger To: Devin Teske Subject: Re: New Boot Loader Menu Message-ID: <20121009220325.00006c9d@unknown> In-Reply-To: References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <20121007183433.000026a6@unknown> <20121007220100.00002d21@unknown> X-Mailer: Claws Mail 3.8.0cvs30 (GTK+ 2.24.10; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: ADECF844006.A42E9 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.574, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL -0.46, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1350417810.78525@oP5Ji2dsQy0MUpqm2bvFvQ X-EBL-Spam-Status: No Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 20:03:34 -0000 On Sun, 7 Oct 2012 14:58:46 -0700 Devin Teske wrote: > > On Oct 7, 2012, at 1:01 PM, Alexander Leidinger wrote: > > The first one is a tribute to the > > poor victim which gives a helping hand, he will not see the boot > > options in case the request is made to change the root FS. The > > second one is that the boot options are modifying the behavior of a > > given kernel (verbose messages, safe mode, acpi), while the > > root-fs/BE/kernel item is choosing a different kernel to boot. > > > > I wholly agree with the separation into 2 submenus and _why_, > however... > > Let's be careful here. > > Be careful to not include "kernel" in that mix. I included kernel in that mix, because loading a different BE/FS is basically loading a different kernel. While it would be nice to be able to chose a kernel if there are multiple in a given FS, I didn't want to imply this here. > In reality, the kernel is loaded by the "start" FICL word provided by > loader.4th and this is done: > > a. before the menu is loaded and > b. irrespective of the menu (done regardless of whether the menu is > enabled or not, perhaps via setting beastie_disable=YES in > loader.conf(5)) > > So by the time the menu is invoked, the only way to change the kernel > is to "unload" and subsequently load the new kernel. > > It should be noted that DruidBSD does not load a kernel before the > menu. Thus in DruidBSD, we _do_ have a kernel selection menu (the > overloaded "boot" FICL word in DruidBSD is coded to load $kernel > right before doing the real boot whereas FreeBSD's overloaded "boot" > FICL word simply invokes the already-loaded kernel that was loaded > before the menu ever started). Is it faster to not load the kernel (time from pushing the power button to the loader menu being reactive to key presses)? If yes, it may be beneficial to do it the way DruidBSD is doing it (it does not cut the time to arrive at multi-user mode, but it improves the response time and has the psychological effect to let the user think it boots faster). And if we want to chose a kernel from a list to boot from, (which I think we want), we should do it too. > It's perhaps good that we're having this discussion out in the open > now, because I actually (as of yet) do not know if jpaetzel, avg, mav > and iX company have plans to (attempt) to allow kernel swapping in > the loader menu. If that is the case, we'll have to broach the topic > of changing that functionality to match what DruidBSD does (defers > kernel loading until "boot" is invoked). If it is not much work, I don't think we should hesitate to do it. It offers the possibility to make enhancements later. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-arch@FreeBSD.ORG Tue Oct 9 20:11:35 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 54EADDF5; Tue, 9 Oct 2012 20:11:35 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id F2F148FC08; Tue, 9 Oct 2012 20:11:34 +0000 (UTC) Received: from outgoing.leidinger.net (p5DD4506C.dip.t-dialin.net [93.212.80.108]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 616FC844006; Tue, 9 Oct 2012 22:11:32 +0200 (CEST) Received: from unknown (IO.Leidinger.net [192.168.1.12]) by outgoing.leidinger.net (Postfix) with ESMTPS id CEA002202; Tue, 9 Oct 2012 22:11:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1349813489; bh=MWq32TZ9Sj+fsEUpH0CNgH67kRcMr9E6fiffu4iWp5g=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=ZOTvetCWwr0Fo9KKtJlxTfEls923ypX8HK9GkQtr/wqeYvupwkzMyWy82TUWym/4o DPRnmdg/Png1cjnIN/j61sdwSbg2aJN2+hYdwzlZely5I3hjdZBqPqbdbf/uDNLv2w 1MQ4B5G72/iRLCg60qzWm7pX0MokRd++PDOuUNLeX2E20wNRY2owcacPSyMvvFI8/y PFrgoz0Wzz5dt+X1CAcSWHMoyetAVAWHo17QOc5iZBzYnPPBaITct9eDnlIJgPVxf6 Z2n0tt0k57D/Bx1ZxJEdJUdl/Vrody1eaWhCw5NhFX8TO2h3NyE/Z9ctmdCgMb4y0U GltfYCFQQwxbQ== Date: Tue, 9 Oct 2012 22:11:27 +0200 From: Alexander Leidinger To: Warner Losh Subject: Re: New Boot Loader Menu Message-ID: <20121009221127.000068c9@unknown> In-Reply-To: <8E009EA2-2274-4B46-8309-410EE8879C08@bsdimp.com> References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <5071D6B5.1010609@FreeBSD.org> <50726C73.10506@FreeBSD.org> <8E009EA2-2274-4B46-8309-410EE8879C08@bsdimp.com> X-Mailer: Claws Mail 3.8.0cvs30 (GTK+ 2.24.10; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 616FC844006.A020A X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.671, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL -0.56, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1350418292.86351@V+mkGN/SkwzA3k6TqXihOg X-EBL-Spam-Status: No Cc: Doug Barton , "freebsd-arch@freebsd.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 20:11:35 -0000 On Mon, 8 Oct 2012 07:54:58 -0600 Warner Losh wrote: > On Oct 8, 2012, at 12:02 AM, Doug Barton wrote: > >>> 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_? > > > > Um, if you don't already know the answers, I really can't help you. > > Go get a book on how to right proper user interfaces. > > I've seen several interfaces that used this paradigm, and it works > well so long as BackSpace doesn't have another binding in that > context. I'd be curious to find a book that says NEVER, EVER do > this. It drives me nuts on my DVD player that I have to hit 'STOP' The good books tell it depends upon the context (like for the edges of a screen... it makes only sense with hard edges which block further movement, not with each edge of a multi-monitor setup). As you told (cut by me), if backspace is not used anywhere, it may make sense to use it for something else than to delete a character. I also agree that it may be good to have backspace as one of multiple ways to go back. Using backspace as a way to go back doesn't shock me in the given context. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-arch@FreeBSD.ORG Tue Oct 9 20:22:20 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 8187912C; Tue, 9 Oct 2012 20:22:20 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 279208FC0A; Tue, 9 Oct 2012 20:22:19 +0000 (UTC) Received: from outgoing.leidinger.net (p5DD4506C.dip.t-dialin.net [93.212.80.108]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id DAFBB844006; Tue, 9 Oct 2012 22:22:14 +0200 (CEST) Received: from unknown (IO.Leidinger.net [192.168.1.12]) by outgoing.leidinger.net (Postfix) with ESMTPS id 79CA42204; Tue, 9 Oct 2012 22:22:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1349814132; bh=+cDkmkVdHOXKG7S3fwY4s+rPLD3lCg5bDPwPWthaG88=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=0FrhuXIT0jQKIHJZtGystawM5E7DKPKaklgwnH4tjA73yt6L4LpKtp/re/31sDWqv zTAN4lNf5XtOsGhnbz5qIMKx5S9StXjf6C5MCVILfiEk4Q3n4tKEVIXGtWie25uEfq jqn4pq7hHjxgMoG3rkNS6trPn+EN21wiF42jBtRbtTKE2wC/+TdI6ktUFAE1CxSrf5 DnkVjWKCEicg8nlMTXiJtxrgqoxFBrJ+B94eCT8QkDkYJL9AEtfLs/JFuUcsYUMvsg Qh7WOsfSTMet8SL377AaoIuQc4hawA2x0kqaP6mfRmgIT6FhLwF2O9pGmO12Rc3fQL OJJA1kvFXDlVA== Date: Tue, 9 Oct 2012 22:22:10 +0200 From: Alexander Leidinger To: Devin Teske Subject: Re: New Boot Loader Menu Message-ID: <20121009222210.00007694@unknown> In-Reply-To: References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <5071D6B5.1010609@FreeBSD.org> <50726C73.10506@FreeBSD.org> <50732CB1.9080900@gmx.de> <71571815-CBF3-4B16-BA77-2828B8BA613C@fisglobal.com> <564537F0-8BB5-4036-8A81-0A3D0B179489@bsdimp.com> <4EA5C2FF-ABFA-4BA6-95CA-8E722F91999E@fisglobal.com> X-Mailer: Claws Mail 3.8.0cvs30 (GTK+ 2.24.10; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: DAFBB844006.A198E X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.735, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL -0.62, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1350418938.14689@Nl2Sw+PbJ/VGIJ5cnAwjJw X-EBL-Spam-Status: No Cc: olli hauer , devin.teske@fisglobal.com, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 20:22:20 -0000 On Tue, 9 Oct 2012 09:38:28 -0700 Devin Teske wrote: > On Oct 9, 2012, at 9:30 AM, Devin Teske wrote: > > I'm looking at my keyboard and nothing really sticks out. > > > > 'M' perhaps for "Back to [M]ain Menu" > > > > There is of course the obvious alternative… we have no keycode and > the user just has to press "1" (that's always been an option). Having 1 in _submenus_ always with the meaning to go back (and if it is easy to make multiple keys working for one action, the backspace key too), and maybe 8 or 9 (and maybe space if multiple keys can be used in the future) always being 'more'/'next' in _submenus_ doesn't sound bad to me. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-arch@FreeBSD.ORG Tue Oct 9 20:30:56 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 DB6253FB; Tue, 9 Oct 2012 20:30:55 +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 9CA298FC12; Tue, 9 Oct 2012 20:30:55 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa03.fnfis.com (8.14.4/8.14.4) with ESMTP id q99KUsC0031119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 9 Oct 2012 15:30:54 -0500 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.31) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 9 Oct 2012 15:30:53 -0500 Subject: Re: New Boot Loader Menu MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="us-ascii" From: Devin Teske In-Reply-To: <20121009220325.00006c9d@unknown> Date: Tue, 9 Oct 2012 13:30:47 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <20121007183433.000026a6@unknown> <20121007220100.00002d21@unknown> <20121009220325.00006c9d@unknown> To: Alexander Leidinger 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-09_05:2012-10-09,2012-10-09,1970-01-01 signatures=0 Cc: Devin Teske , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 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: Tue, 09 Oct 2012 20:30:56 -0000 On Oct 9, 2012, at 1:03 PM, Alexander Leidinger wrote: > On Sun, 7 Oct 2012 14:58:46 -0700 Devin Teske > wrote: >=20 >>=20 >> On Oct 7, 2012, at 1:01 PM, Alexander Leidinger wrote: >=20 >>> The first one is a tribute to the >>> poor victim which gives a helping hand, he will not see the boot >>> options in case the request is made to change the root FS. The >>> second one is that the boot options are modifying the behavior of a >>> given kernel (verbose messages, safe mode, acpi), while the >>> root-fs/BE/kernel item is choosing a different kernel to boot. >>>=20 >>=20 >> I wholly agree with the separation into 2 submenus and _why_, >> however... >>=20 >> Let's be careful here. >>=20 >> Be careful to not include "kernel" in that mix. >=20 > I included kernel in that mix, because loading a different BE/FS is > basically loading a different kernel. While it would be nice to be able > to chose a kernel if there are multiple in a given FS, I didn't want to > imply this here. >=20 You make a very astute observation here. I'm really thinking that the "promised land" is to have a [proposed] kernel= selection menu dynamically enumerate all kernels available on the selected= root device. I think we should discuss/explore this further at the up-coming DevSummit. = I'm requesting time in the Talks -- I'm thinking this is perfect to add to = my time-slot. >> In reality, the kernel is loaded by the "start" FICL word provided by >> loader.4th and this is done: >>=20 >> a. before the menu is loaded and >> b. irrespective of the menu (done regardless of whether the menu is >> enabled or not, perhaps via setting beastie_disable=3DYES in >> loader.conf(5)) >>=20 >> So by the time the menu is invoked, the only way to change the kernel >> is to "unload" and subsequently load the new kernel. >>=20 >> It should be noted that DruidBSD does not load a kernel before the >> menu. Thus in DruidBSD, we _do_ have a kernel selection menu (the >> overloaded "boot" FICL word in DruidBSD is coded to load $kernel >> right before doing the real boot whereas FreeBSD's overloaded "boot" >> FICL word simply invokes the already-loaded kernel that was loaded >> before the menu ever started). >=20 > Is it faster to not load the kernel (time from pushing the power > button to the loader menu being reactive to key presses)? Absolutely! > If yes, it > may be beneficial to do it the way DruidBSD is doing it (it does not > cut the time to arrive at multi-user mode, but it improves the > response time and has the psychological effect to let the user think > it boots faster). I like this idea. > And if we want to chose a kernel from a list to boot > from, (which I think we want), we should do it too. >=20 I'm with you. >> It's perhaps good that we're having this discussion out in the open >> now, because I actually (as of yet) do not know if jpaetzel, avg, mav >> and iX company have plans to (attempt) to allow kernel swapping in >> the loader menu. If that is the case, we'll have to broach the topic >> of changing that functionality to match what DruidBSD does (defers >> kernel loading until "boot" is invoked). >=20 > If it is not much work, I don't think we should hesitate to do it. It > offers the possibility to make enhancements later. >=20 Ok, let me put a patch together for review. --=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. From owner-freebsd-arch@FreeBSD.ORG Tue Oct 9 20:32:31 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 160ED4F4; Tue, 9 Oct 2012 20:32:31 +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 C630D8FC18; Tue, 9 Oct 2012 20:32:29 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa01.fnfis.com (8.14.4/8.14.4) with ESMTP id q99KWNKL015432 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 9 Oct 2012 15:32:28 -0500 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.31) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 9 Oct 2012 15:32:16 -0500 Subject: Re: New Boot Loader Menu MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Devin Teske In-Reply-To: <20121009222210.00007694@unknown> Date: Tue, 9 Oct 2012 13:32:12 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <5071D6B5.1010609@FreeBSD.org> <50726C73.10506@FreeBSD.org> <50732CB1.9080900@gmx.de> <71571815-CBF3-4B16-BA77-2828B8BA613C@fisglobal.com> <564537F0-8BB5-4036-8A81-0A3D0B179489@bsdimp.com> <4EA5C2FF-ABFA-4BA6-95CA-8E722F91999E@fisglobal.com> <20121009222210.00007694@unknown> To: Alexander Leidinger 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-09_05:2012-10-09,2012-10-09,1970-01-01 signatures=0 Cc: olli hauer , Devin Teske , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 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: Tue, 09 Oct 2012 20:32:31 -0000 On Oct 9, 2012, at 1:22 PM, Alexander Leidinger wrote: > On Tue, 9 Oct 2012 09:38:28 -0700 Devin Teske > wrote: >=20 >> On Oct 9, 2012, at 9:30 AM, Devin Teske wrote: >=20 >>> I'm looking at my keyboard and nothing really sticks out. >>>=20 >>> 'M' perhaps for "Back to [M]ain Menu" >>>=20 >>=20 >> There is of course the obvious alternative=85 we have no keycode and >> the user just has to press "1" (that's always been an option). >=20 > Having 1 in _submenus_ always with the meaning to go back (and if it is > easy to make multiple keys working for one action, the backspace key > too), and maybe 8 or 9 (and maybe space if multiple keys can be used in > the future) always being 'more'/'next' in _submenus_ doesn't sound bad > to me. >=20 I'm sold. I've heard no better suggestions (and the great feedback so far h= as lead me to believe this is the only sensible approach). --=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. From owner-freebsd-arch@FreeBSD.ORG Tue Oct 9 22:26:26 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 ABC2E1000 for ; Tue, 9 Oct 2012 22:26:26 +0000 (UTC) (envelope-from mail@mailsu.ru) Received: from mailsu.ru (mailsu.ru [95.128.246.31]) by mx1.freebsd.org (Postfix) with ESMTP id 267048FC18 for ; Tue, 9 Oct 2012 22:26:25 +0000 (UTC) Received: from mailsu.ru by mailsu.ru (MDaemon FREE v12.5.3) with ESMTP id md50000621781.msg for ; Wed, 10 Oct 2012 02:26:12 +0400 X-Authenticated-Sender: mail@mailsu.ru X-Return-Path: mail@mailsu.ru X-Envelope-From: mail@mailsu.ru X-MDaemon-Deliver-To: freebsd-arch@freebsd.org From: "=?Windows-1251?B?0eXw4+Xp?=" Subject: =?Windows-1251?B?ZnJlZWJzZGFyY2hmcmVlYnNkICDiIO7y5OXrIOvu4+jx8ujq6CDo6+gg8e3g4ebl7ej/?= To: "freebsd-arch" MIME-Version: 1.0 Organization: =?Windows-1251?B?w8DQwM3SwCDL7uPo8fLo6iDD7OHVIEJlcmxpbg==?= Date: Wed, 10 Oct 2012 02:26:11 +0400 Message-Id: <20121009222626.ABC2E1000@hub.freebsd.org> Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 22:26:26 -0000 =D3=E2=E0=E6=E0=E5=EC=FB=E5 =C4=E0=EC=FB =E8 =C3=EE=F1=EF=EE=E4=E0, =20 =ED=F3=E6=ED=FB =E4=E0=EB=FC=ED=E5=E9=F8=E8=E5 =E8=ED=F1=F2=F0=F3=EA=F6=E8= =E8 =EF=EE =C2=E0=F8=E5=EC=F3 =E3=F0=F3=E7=F3. =C3=F0=F3=E7 =E4=EB=FF =C2= =E0=F8=E5=E9 =EA=EE=EC=EF=E0=ED=E8=E8 - 2 =EC=E5=F1=F2=E0 17 =F3=E3, =F1=EA= =EE=F0=E5=E5 =E2=F1=E5=E3=EE =EE=F8=E8=E1=EE=F7=ED=EE, =EF=EE=EF=E0=EB =EA = =ED=E0=EC =ED=E0 =F1=EA=EB=E0=E4 =E2 =C1=E5=F0=EB=E8=ED.=20 =D1=EE=EE=E1=F9=E8=F2=E5 =ED=E0=EC =EA=F3=E4=E0 =C2=E0=EC =E5=E3=EE =EE=F2= =EF=F0=E0=E2=E8=F2=FC. =CF=EE=F1=F2=E0=F0=E0=E9=F2=E5=F1=FC =EE=F2=E2=E5=F2= =E8=F2=FC =EA=E0=EA =EC=EE=E6=ED=EE =EE=EF=E5=F0=E0=F2=E8=E2=ED=E5=E5!=20 =C3=E0=F0=E0=ED=F2=E0 =C3=EC=E1=D5=20 =D1 =F3=E2.=D1=E5=F0=E3=E5=E9 =EE=F2=E2=E5=F2 =EC=EE=E6=ED=EE =EF=F0=E8=F1=EB=E0=F2=FC =F2=E0=EA=E6=E5 = =ED=E0 =E0=E4=F0=E5=F1 garantaorder@mail.ru This message was delivered by MDaemon - http://www.altn.com/MDaemon/ From owner-freebsd-arch@FreeBSD.ORG Tue Oct 9 22:26:31 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 AF75F6F; Tue, 9 Oct 2012 22:26:31 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 72D888FC1E; Tue, 9 Oct 2012 22:26:31 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so6336789pad.13 for ; Tue, 09 Oct 2012 15:26:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=LNBm/N2444uKJVGuhxgzjueqmdqfGhjv+3L4u6eWmlk=; b=BP6x776m/drwcH09BjmXnSIsFnKlNGuqSbgPt3sapuy92kHGhayncia/rLgf5Lg91s s7FCSzYOCE48mOKYcyCieGqh3fFaQpbFTWzqW+XPbOlUivT0IzmQ3mWyHAo6nBrZAgqt bWthK6RNnbOMNj8Hx7j6fYaFHymW+LXbZYXGs5nWnn5rxjq1qyW21Qm4oDDbfzyA9/5a /kpe9B6UnxnvUtWYa8U8pyLjXfgLOv8jrOj2kLJoPC4hb2fZ85QkMVVYUgm6iEtKHrRD QUu/1F5DxdRg7zo+jn4Wt5VYed1GQ9bU52iMG1YksYaUs/tBrd4O98oYS7eJr4TJuto9 s8ZQ== MIME-Version: 1.0 Received: by 10.68.202.6 with SMTP id ke6mr67054795pbc.82.1349821591275; Tue, 09 Oct 2012 15:26:31 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.223.136 with HTTP; Tue, 9 Oct 2012 15:26:31 -0700 (PDT) In-Reply-To: References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <5071D6B5.1010609@FreeBSD.org> <50726C73.10506@FreeBSD.org> <50732CB1.9080900@gmx.de> <71571815-CBF3-4B16-BA77-2828B8BA613C@fisglobal.com> <564537F0-8BB5-4036-8A81-0A3D0B179489@bsdimp.com> <4EA5C2FF-ABFA-4BA6-95CA-8E722F91999E@fisglobal.com> <20121009222210.00007694@unknown> Date: Tue, 9 Oct 2012 15:26:31 -0700 X-Google-Sender-Auth: h0cDODBB-hUiWizz6TAdzoEXflA Message-ID: Subject: Re: New Boot Loader Menu From: Adrian Chadd To: Devin Teske Content-Type: text/plain; charset=ISO-8859-1 Cc: olli hauer , Alexander Leidinger , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 22:26:31 -0000 Since there's been such a large amount of discussion about this, how about you put together a web page with the legacy, current and proposed menu structure, separate from any of this discussion? That way you can have some concept of "expected menu behaviour" regardless of what the menu contents are.. Thanks, Adrian From owner-freebsd-arch@FreeBSD.ORG Wed Oct 10 02:39:30 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 D4EE7ECF for ; Wed, 10 Oct 2012 02:39:30 +0000 (UTC) (envelope-from chengqimosaic@sina.com) Received: from smtp.sina.com.cn (mail7-211.sinamail.sina.com.cn [202.108.7.211]) by mx1.freebsd.org (Postfix) with ESMTP id 80F938FC12 for ; Wed, 10 Oct 2012 02:39:29 +0000 (UTC) Received: from irja2-156.sinamail.sina.com.cn (unknown [10.69.2.156]) by smtp.sina.com.cn (SINAMAIL) with ESMTP id 857D188ED63 for ; Wed, 10 Oct 2012 10:39:28 +0800 (CST) X-Originating-IP: [182.37.136.154] X-Auth-ID: chengqimosaic@sina.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIKAKU/KE+2JYia/3poAIFfnD4+eJM4jH8IhkoOgRmDZ4ELBIZOiUOETIo2 Received: from unknown (HELO eosgui) ([182.37.136.154]) by irja2-156.sinamail.sina.com.cn with ESMTP; 10 Oct 2012 10:39:28 +0800 Date: Wed, 10 Oct 2012 10:43:10 +0800 From: "jessaic" To: "freebsd-arch" Subject: Re:crystal mosaic/provide sample Message-ID: <201210101043108758410@sina.com> X-Mailer: Foxmail 6, 10, 201, 20 [cn] MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: glassmosaic@188.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 02:39:30 -0000 RGVhciBTaXIgb3IgTWFkYW0sDQoNClRoaXMgaXMgSmVzc2ljYSBmcm9tIENoZW5ncWkgR2xhc3Mg TW9zYWljIENvLixMdGQuIFdlIGhhdmUgYSBmYWN0b3J5IHNwZWNpYWxpemVkIGluIHByb2R1Y2lu ZyBraW5kcyBvZiBnbGFzcyBtb3NhaWMgaW5jbHVkaW5nIDE1eDE1eDRtbSwyMHgyMHg0bW0sMjN4 MjN4NG1tLDI1eDI1eDRtbSw1MHg1MHg0bW0sDQozMHgzMHg2bW0sMzB4MzB4OG1tLDUweDUweDEy bW0sMTV4MTV4OG1tLDUweDE1eDhtbSBldGMuDQpPdGhlcndpc2UseW91ciBzcGVjaWFsIGRldGFp bHMgYWJvdXQgaXQgd2Ugd2lsbCBkbyBvdXIgYmVzdCB0byBjb29wZXJhdGUgd2l0aCB5b3UuDQog DQpMb29raW5nIGZvcndhcmQgdG8geW91ciBwcm9tcHQgcmVwbHkuDQoNCg0KUmVnYXJkcywNCkpl c3NpY2EgDQoNClNreXBlOmplc3NpY2EyOTg1Ng0KVGVsOjg2LTUzOS03MTYyODc4DQpGYXg6ODYt NTM5LTgxMjcyMTU= From owner-freebsd-arch@FreeBSD.ORG Wed Oct 10 10:44:41 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 1953DC68; Wed, 10 Oct 2012 10:44:41 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id C2D4E8FC17; Wed, 10 Oct 2012 10:44:40 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 047756706; Wed, 10 Oct 2012 12:44:40 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id BD85593C3; Wed, 10 Oct 2012 12:44:39 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Devin Teske Subject: Re: New Boot Loader Menu References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <5071D6B5.1010609@FreeBSD.org> <50726C73.10506@FreeBSD.org> <50732CB1.9080900@gmx.de> <71571815-CBF3-4B16-BA77-2828B8BA613C@fisglobal.com> <515694A9-3D0F-4150-8865-F518072C5EC6@fisglobal.com> <1349798845.1123.10.camel@revolution.hippie.lan> <6389190E-16B1-4B32-937D-677B966EB7AA@fisglobal.com> Date: Wed, 10 Oct 2012 12:44:39 +0200 In-Reply-To: <6389190E-16B1-4B32-937D-677B966EB7AA@fisglobal.com> (Devin Teske's message of "Tue, 9 Oct 2012 09:24:37 -0700") Message-ID: <86626i61yg.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Garrett Cooper , Ian Lepore , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 10:44:41 -0000 Devin Teske writes: > Ian Lepore writes: > > How about Escape, that often means go-back in a UI (common in BIOS > > config screens), and I didn't see it on the list of forbidden keys. > The main-menu uses it to drop the user to the interactive "ok>" > prompt. So? That's conceptually the same thing. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Wed Oct 10 16:21:07 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 D4F74907; Wed, 10 Oct 2012 16:21:07 +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 8A5718FC12; Wed, 10 Oct 2012 16:21:07 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa04.fnfis.com (8.14.4/8.14.4) with ESMTP id q9AGKkJc003237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 10 Oct 2012 11:21:01 -0500 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.31) with Microsoft SMTP Server (TLS) id 14.2.309.2; Wed, 10 Oct 2012 11:20:56 -0500 Subject: Re: New Boot Loader Menu MIME-Version: 1.0 (Apple Message framework v1283) From: Devin Teske In-Reply-To: Date: Wed, 10 Oct 2012 09:20:48 -0700 Message-ID: References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <5071D6B5.1010609@FreeBSD.org> <50726C73.10506@FreeBSD.org> <50732CB1.9080900@gmx.de> <71571815-CBF3-4B16-BA77-2828B8BA613C@fisglobal.com> <564537F0-8BB5-4036-8A81-0A3D0B179489@bsdimp.com> <4EA5C2FF-ABFA-4BA6-95CA-8E722F91999E@fisglobal.com> <20121009222210.00007694@unknown> To: Adrian Chadd 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-10_06:2012-10-10,2012-10-10,1970-01-01 signatures=0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: olli hauer , Alexander Leidinger , Devin Teske , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 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: Wed, 10 Oct 2012 16:21:07 -0000 On Oct 9, 2012, at 3:26 PM, Adrian Chadd wrote: > Since there's been such a large amount of discussion about this, how > about you put together a web page with the legacy, current and > proposed menu structure, separate from any of this discussion? >=20 > That way you can have some concept of "expected menu behaviour" > regardless of what the menu contents are.. >=20 Sounds like an excellent plan. In the meantime, I'd like to move forward with my enhancements *without* ch= anging the user interface/experience. For example, gnn brought this to my attention (so I filed a PR against myse= lf to fix it). See attached patch.txt. http://www.freebsd.org/cgi/query-pr.cgi?pr=3D172529 --=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. From owner-freebsd-arch@FreeBSD.ORG Thu Oct 11 16:01:39 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 E36D4AF7 for ; Thu, 11 Oct 2012 16:01:39 +0000 (UTC) (envelope-from nizhniynovgorod@mytailor.ru) Received: from relay-out3.mail.masterhost.ru (relay-out3.mail.masterhost.ru [83.222.23.76]) by mx1.freebsd.org (Postfix) with ESMTP id 687998FC08 for ; Thu, 11 Oct 2012 16:01:39 +0000 (UTC) Received: from [UNAVAILABLE] ([81.195.50.210] helo=81.195.50.210) by relay3.mail.masterhost.ru with esmtp envelope from authenticated with president@iba-moscow.ru message id 1TMLCb-000DHi-O8 for freebsd-arch@freebsd.org; Thu, 11 Oct 2012 20:01:38 +0400 From: "=?utf-8?B?ItCY0LzQv9C10YDQsNGC0L7RgNGB0LrQuNC5INCf0L7RgNGC0L3QvtC5INCyINCd0LjQttC90LXQvCDQndC+0LLQs9C+0YDQvtC00LUi?=" Subject: =?utf-8?B?W0JVTEtdItCY0LzQv9C10YDQsNGC0L7RgNGB0LrQuNC5INCf0L7RgNGC0L3QvtC5IiDQsiDQstCw0YjQtdC8INCz0L7RgNC+0LTQteKAnQ==?= To: "freebsd-arch" MIME-Version: 1.0 Organization: The Imperial Tailoring Co. Date: Thu, 11 Oct 2012 20:01:36 +0400 X-Mailer-MsgId: b5ADAIxNB0EuZ0Mx5eGZsQmd3bDJtdGV2tNHBtYj5rd3JfZ2o4bXAscHM2B0QwLj0U3NTY3KzRCLjc= X-SpamTest-Envelope-From: nizhniynovgorod@mytailor.ru X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 37717 [Oct 11 2012] X-SpamTest-Info: {relay has no DNS name} X-SpamTest-Method: none X-SpamTest-Rate: 40 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release Message-Id: <20121011160139.E36D4AF7@hub.freebsd.org> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 16:01:40 -0000 =EF=BB=BFVIP =D1=8D=D0=BA=D1=81=D0=BA=D0=BB=D1=8E=D0=B7=D0=B8=D0=B2=D1= =8B=D0=BD=D0=BE=D0=B5 =D0=BF=D1=80=D0=B5=D0=B4=D0=BB=D0=BE=D0=B6=D0=B5= =D0=BD=D0=B8=D0=B5=20 10.10.2012 =D0=B3=D0=BE=D0=B4=D0=B0 =20 "=D0=98=D0=BC=D0=BF=D0=B5=D1=80=D0=B0=D1=82=D0=BE=D1=80=D1=81=D0=BA=D0= =B8=D0=B9 =D0=9F=D0=BE=D1=80=D1=82=D0=BD=D0=BE=D0=B9" =D0=B2 =D0=B2=D0= =B0=D1=88=D0=B5=D0=BC =D0=B3=D0=BE=D1=80=D0=BE=D0=B4=D0=B5=E2=80=9D =C2=AB=D0=98=D0=BC=D0=BF=D0=B5=D1=80=D0=B0=D1=82=D0=BE=D1=80=D1=81=D0=BA= =D0=B8=D0=B9 =D0=BF=D0=BE=D1=80=D1=82=D0=BD=D0=BE=D0=B9=C2=BB =D0=BF=D0= =BE=D1=81=D0=B5=D1=82=D0=B8=D1=82 =D0=9D=D0=B8=D0=B6=D0=BD=D0=B8=D0=B9= =D0=9D=D0=BE=D0=B2=D0=B3=D0=BE=D1=80=D0=BE=D0=B4 =20 =D0=92 =D0=9D=D0=B8=D0=B6=D0=BD=D0=B5=D0=BC =D0=9D=D0=BE=D0=B2=D0=B3=D0= =BE=D1=80=D0=BE=D0=B4=D0=B5 =D1=81 15 =D0=BF=D0=BE 21 =D0=BE=D0=BA=D1=82= =D1=8F=D0=B1=D1=80=D1=8F =D0=B2 =D0=B3=D0=BE=D1=81=D1=82=D0=B8=D0=BD=D0= =B8=D1=86=D0=B5 "=D0=9E=D0=BA=D0=B0" =D1=81 9.00 =D0=B4=D0=BE 20.00 =D0= =B1=D1=83=D0=B4=D0=B5=D1=82 =D1=80=D0=B0=D0=B1=D0=BE=D1=82=D0=B0=D1=82= =D1=8C =D1=81=D0=BF=D0=B5=D1=86=D0=B8=D0=B0=D0=BB=D0=B8=D1=81=D1=82 =D0= =BA=D0=BE=D0=BC=D0=BF=D0=B0=D0=BD=D0=B8=D0=B8 =C2=AB=D0=98=D0=BC=D0=BF= =D0=B5=D1=80=D0=B0=D1=82=D0=BE=D1=80=D1=81=D0=BA=D0=B8=D0=B9 =D0=BF=D0= =BE=D1=80=D1=82=D0=BD=D0=BE=D0=B9=C2=BB =D0=9D=D0=B8=D1=80=D0=B0=D0=B4= =D0=B6 =D0=9A=D1=85=D0=B5=D0=BC=D0=BD=D0=B0=D0=BD=D0=B8. =D0=A3 =D0=BD= =D0=B8=D0=B6=D0=B5=D0=B3=D0=BE=D1=80=D0=BE=D0=B4=D1=81=D0=BA=D0=B8=D1=85= =D0=B3=D0=BE=D1=81=D0=BF=D0=BE=D0=B4 =D0=B2=D0=BF=D0=B5=D1=80=D0=B2=D1= =8B=D0=B5 =D0=BF=D0=BE=D1=8F=D0=B2=D0=B8=D1=82=D1=81=D1=8F =D1=8D=D0=BA= =D1=81=D0=BA=D0=BB=D1=8E=D0=B7=D0=B8=D0=B2=D0=BD=D1=8B=D0=B9 =D1=88=D0= =B0=D0=BD=D1=81 =D0=B7=D0=B0=D0=BA=D0=B0=D0=B7=D0=B0=D1=82=D1=8C =D0=BA= =D0=BE=D1=81=D1=82=D1=8E=D0=BC, =D0=BF=D0=B0=D0=BB=D1=8C=D1=82=D0=BE =D0= =B8=D0=BB=D0=B8 =D0=B0=D0=BA=D1=81=D0=B5=D1=81=D1=81=D1=83=D0=B0=D1=80= =D1=8B, =D0=B2=D1=8B=D0=BF=D0=BE=D0=BB=D0=BD=D0=B5=D0=BD=D0=BD=D1=8B=D0= =B5 =D0=BF=D0=BE =D0=B8=D0=BD=D0=B4=D0=B8=D0=B2=D0=B8=D0=B4=D1=83=D0=B0= =D0=BB=D1=8C=D0=BD=D1=8B=D0=BC =D0=BC=D0=B5=D1=80=D0=BA=D0=B0=D0=BC =D0= =B7=D0=B0=D0=BA=D0=B0=D0=B7=D1=87=D0=B8=D0=BA=D0=B0, =D1=83 =D0=B8=D0=BD= =D0=B4=D0=B8=D0=B9=D1=81=D0=BA=D0=B8=D1=85 =D1=82=D0=B2=D0=BE=D1=80=D1= =86=D0=BE=D0=B2. =20 =D0=9D=D0=B8=D1=80=D0=B0=D0=B4=D0=B6 =D0=9A=D1=85=D0=B5=D0=BC=D0=BD=D0= =B0=D0=BD=D0=B8 =E2=80=94 =D0=BF=D0=BE=D1=81=D0=BB=D0=B5=D0=B4=D0=BD=D0= =B8=D0=B9 =D1=83=D1=87=D0=B5=D0=BD=D0=B8=D0=BA =D1=83 =D0=B3=D0=BB=D0=B0= =D0=B2=D1=8B =D0=BA=D0=BE=D0=BC=D0=BF=D0=B0=D0=BD=D0=B8=D0=B8 =C2=AB=D0= =98=D0=BC=D0=BF=D0=B5=D1=80=D0=B0=D1=82=D0=BE=D1=80=D1=81=D0=BA=D0=B8=D0= =B9 =D0=BF=D0=BE=D1=80=D1=82=D0=BD=D0=BE=D0=B9=C2=BB =D0=A1=D1=8D=D0=BC= =D0=BC=D0=B8 =D0=9A=D0=BE=D1=82=D0=B2=D0=B0=D0=BD=D0=B8. =D0=9C=D0=BE=D0= =BB=D0=BE=D0=B4=D0=BE=D0=B9, =D1=82=D0=B0=D0=BB=D0=B0=D0=BD=D1=82=D0=BB= =D0=B8=D0=B2=D1=8B=D0=B9, =D0=BA=D1=80=D0=B5=D0=B0=D1=82=D0=B8=D0=B2=D0= =BD=D1=8B=D0=B9 =D1=87=D0=B5=D0=BB=D0=BE=D0=B2=D0=B5=D0=BA =D1=81 =D0=B2= =D0=B5=D0=BB=D0=B8=D0=BA=D0=BE=D0=BB=D0=B5=D0=BF=D0=BD=D1=8B=D0=BC =D0= =B7=D0=BD=D0=B0=D0=BD=D0=B8=D0=B5=D0=BC =D0=B4=D0=BB=D1=8F =D1=81=D0=B2= =D0=BE=D0=B8=D1=85 =D0=BB=D0=B5=D1=82. =D0=91=D0=BB=D0=B0=D0=B3=D0=BE=D0= =B4=D0=B0=D1=80=D1=8F =D0=B5=D0=B3=D0=BE =D0=BE=D0=B1=D0=BE=D1=81=D0=BD= =D0=BE=D0=B2=D0=B0=D0=BD=D0=BD=D1=8B=D0=BC =D0=B0=D1=80=D0=B3=D1=83=D0= =BC=D0=B5=D0=BD=D1=82=D0=B0=D0=BC =D0=BA=D0=BE=D0=BC=D0=BF=D0=B0=D0=BD= =D0=B8=D1=8F =D0=B2=D0=BE=D0=BF=D0=BB=D0=BE=D1=82=D0=B8=D0=BB=D0=B0 =D0= =B2 =D0=B6=D0=B8=D0=B7=D0=BD=D1=8C =D0=BD=D0=BE=D0=B2=D1=8B=D0=B9 =D0=BF= =D1=80=D0=BE=D0=B5=D0=BA=D1=82 =C2=AB=D0=9F=D1=83=D1=82=D0=B5=D1=88=D0= =B5=D1=81=D1=82=D0=B2=D0=B8=D0=B5 =D0=BF=D0=BE=D1=80=D1=82=D0=BD=D0=BE= =D0=B3=D0=BE=C2=BB, =D0=BA=D0=BE=D1=82=D0=BE=D1=80=D1=8B=D0=B9 =D0=BF=D0= =BE=D0=B7=D0=B2=D0=BE=D0=BB=D0=B8=D1=82 =D0=B1=D0=B8=D0=B7=D0=BD=D0=B5= =D1=81=D0=BC=D0=B5=D0=BD=D0=B0=D0=BC =D0=B8 =D0=BF=D0=BE=D0=BB=D0=B8=D1= =82=D0=B8=D0=BA=D0=B0=D0=BC =D0=B2 =D1=88=D0=B5=D1=81=D1=82=D0=B8 =D0=BA= =D1=80=D1=83=D0=BF=D0=BD=D0=B5=D0=B9=D1=88=D0=B8=D1=85 =D0=B3=D0=BE=D1= =80=D0=BE=D0=B4=D0=B0=D1=85 =D0=A0=D0=BE=D1=81=D1=81=D0=B8=D0=B8 =D0=BF= =D0=BE=D0=BB=D1=83=D1=87=D0=B8=D1=82=D1=8C =D1=83=D1=81=D0=BB=D1=83=D0= =B3=D0=B8 =D0=BE=D0=B4=D0=BD=D0=B8=D1=85 =D0=B8=D0=B7 =D0=BB=D1=83=D1=87= =D1=88=D0=B8=D1=85 =D0=BF=D0=BE=D1=80=D1=82=D0=BD=D1=8B=D1=85 =D0=B2 =D0= =BC=D0=B8=D1=80=D0=B5 .=20 =20 =D0=9D=D0=B8=D0=B6=D0=B5=D0=B3=D0=BE=D1=80=D0=BE=D0=B4=D1=81=D0=BA=D0=B8= =D0=B5 =D0=B1=D0=B8=D0=B7=D0=BD=D0=B5=D1=81=D0=BC=D0=B5=D0=BD=D1=8B =D1= =81=D0=BC=D0=BE=D0=B3=D1=83=D1=82 =D0=B7=D0=B0=D0=BA=D0=B0=D0=B7=D0=B0= =D1=82=D1=8C =D1=83 =D0=BC=D0=B0=D1=81=D1=82=D0=B5=D1=80=D0=B0 =D0=BF=D0= =BE=D1=88=D0=B8=D0=B2 =D0=BF=D0=B8=D0=B4=D0=B6=D0=B0=D0=BA=D0=B0, =D0=B1= =D1=80=D1=8E=D0=BA, =D1=80=D1=83=D0=B1=D0=B0=D1=88=D0=B5=D0=BA, =D0=BF= =D0=B0=D0=BB=D1=8C=D1=82=D0=BE, =D1=81=D0=BC=D0=BE=D0=BA=D0=B8=D0=BD=D0= =B3=D0=BE=D0=B2 =D0=B8 =D1=81=D0=B2=D0=B0=D0=B4=D0=B5=D0=B1=D0=BD=D1=8B= =D1=85 =D0=BA=D0=BE=D1=81=D1=82=D1=8E=D0=BC=D0=BE=D0=B2. =D0=9A=D1=80=D0= =BE=D0=BC=D0=B5 =D1=82=D0=BE=D0=B3=D0=BE =D0=98=D0=BC=D0=BF=D0=B5=D1=80= =D0=B0=D1=82=D0=BE=D1=80=D1=81=D0=BA=D0=B8=D0=B9 =D0=9F=D0=BE=D1=80=D1= =82=D0=BD=D0=BE=D0=B9 =D1=81=D0=BC=D0=BE=D0=B6=D0=B5=D1=82 =D1=81=D0=BE= =D0=B7=D0=B4=D0=B0=D1=82=D1=8C =D1=8D=D0=BA=D1=81=D0=BA=D0=BB=D1=8E=D0= =B7=D0=B8=D0=B2=D0=BD=D1=83=D1=8E =D0=BE=D0=B1=D1=83=D0=B2=D1=8C =D0=B8= =D0=B0=D0=BA=D1=81=D0=B5=D1=81=D1=81=D1=83=D0=B0=D1=80=D1=8B: =D0=B3=D0= =B0=D0=BB=D1=81=D1=82=D1=83=D0=BA=D0=B8, =D1=88=D0=B0=D1=80=D1=84=D1=8B= , =D0=BF=D0=BB=D0=B0=D1=82=D0=BA=D0=B8, =D0=BD=D0=BE=D1=81=D0=BA=D0=B8= =D0=B8 =D0=B4=D0=B0=D0=B6=D0=B5 =D0=B7=D0=B0=D0=BF=D0=BE=D0=BD=D0=BA=D0= =B8. =D0=92 =D1=86=D0=B5=D0=BB=D0=BE=D0=BC =D0=B2=D1=81=D0=B5, =D1=87=D1= =82=D0=BE=D0=B1=D1=8B =D1=81=D0=BE=D0=B7=D0=B4=D0=B0=D1=82=D1=8C =D0=BF= =D0=BE=D0=BB=D0=BD=D0=BE=D1=81=D1=82=D1=8C=D1=8E =D0=BD=D0=B5=D0=BF=D0= =BE=D0=B2=D1=82=D0=BE=D1=80=D0=B8=D0=BC=D1=8B=D0=B9 luxury =D0=BE=D0=B1= =D1=80=D0=B0=D0=B7.=20 =20 =D0=92=D1=81=D0=B5 =D0=B8=D0=B7=D0=B4=D0=B5=D0=BB=D0=B8=D1=8F =D0=B8=D0= =B7=D0=B3=D0=BE=D1=82=D0=B0=D0=B2=D0=BB=D0=B8=D0=B2=D0=B0=D1=8E=D1=82=D1= =81=D1=8F =D0=B8=D0=B7 =D0=BD=D0=B0=D1=82=D1=83=D1=80=D0=B0=D0=BB=D1=8C= =D0=BD=D0=BE=D0=B3=D0=BE =D1=81=D1=8B=D1=80=D1=8C=D1=8F: =D1=81=D0=B2=D0= =B5=D1=80=D1=85=D1=82=D0=BE=D0=BD=D0=BA=D0=BE=D0=B9 =D1=88=D0=B5=D1=80= =D1=81=D1=82=D0=B8, =D0=BC=D0=BE=D1=85=D0=B5=D1=80=D0=B0, =D1=88=D0=B5= =D0=BB=D0=BA=D0=B0, =D0=BA=D0=B0=D1=88=D0=B5=D0=BC=D0=B8=D1=80=D0=B0. = "=D0=98=D0=BC=D0=BF=D0=B5=D1=80=D0=B0=D1=82=D0=BE=D1=80=D1=81=D0=BA=D0= =B8=D0=B9 =D0=9F=D0=BE=D1=80=D1=82=D0=BD=D0=BE=D0=B9" =D1=8F=D0=B2=D0=BB= =D1=8F=D0=B5=D1=82=D1=81=D1=8F =D0=BE=D1=84=D0=B8=D1=86=D0=B8=D0=B0=D0= =BB=D1=8C=D0=BD=D1=8B=D0=BC =D0=B4=D0=B8=D1=81=D1=82=D1=80=D0=B8=D0=B1= =D1=8C=D1=8E=D1=82=D0=BE=D1=80=D0=BE=D0=BC =D0=B1=D0=B5=D0=BB=D1=8C=D0= =B3=D0=B8=D0=B9=D1=81=D0=BA=D0=BE=D0=B9 =D1=84=D0=B8=D1=80=D0=BC=D1=8B= Scabal - =D0=BE=D0=B4=D0=BD=D0=BE=D0=B3=D0=BE =D0=B8=D0=B7 =D0=B2=D0=B5= =D0=B4=D1=83=D1=89=D0=B8=D1=85 =D0=BF=D0=BE=D1=81=D1=82=D0=B0=D0=B2=D1= =89=D0=B8=D0=BA=D0=BE=D0=B2 =D1=8D=D0=BB=D0=B8=D1=82=D0=BD=D1=8B=D1=85= =D1=82=D0=BA=D0=B0=D0=BD=D0=B5=D0=B9. =D0=A2=D0=B0=D0=BA=D0=B6=D0=B5 = =D0=BC=D0=B0=D1=81=D1=82=D0=B5=D1=80=D0=B0 =D0=BA=D0=BE=D0=BC=D0=BF=D0= =B0=D0=BD=D0=B8=D0=B8 =D0=B8=D1=81=D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D1=83= =D1=8E=D1=82 =D1=82=D0=BA=D0=B0=D0=BD=D0=B8 Charles Clayton, Loro Pian= a, Holland & Sherry, Fintes, Ermenegildo Zegna =D0=B8 Dormeuil.=20 =20 =D0=92 =D1=87=D0=B8=D1=81=D0=BB=D0=BE =D0=BF=D0=BE=D1=87=D0=B8=D1=82=D0= =B0=D1=82=D0=B5=D0=BB=D0=B5=D0=B9 =D0=B8 =D0=BF=D0=BE=D1=81=D1=82=D0=BE= =D1=8F=D0=BD=D0=BD=D1=8B=D1=85 =D0=BA=D0=BB=D0=B8=D0=B5=D0=BD=D1=82=D0= =BE=D0=B2 =C2=AB=D0=98=D0=BC=D0=BF=D0=B5=D1=80=D0=B0=D1=82=D0=BE=D1=80= =D1=81=D0=BA=D0=BE=D0=B3=D0=BE =D0=BF=D0=BE=D1=80=D1=82=D0=BD=D0=BE=D0= =B3=D0=BE=C2=BB =D0=B2=D1=85=D0=BE=D0=B4=D1=8F=D1=82 8 =D0=B3=D0=BB=D0= =B0=D0=B2 =D0=B3=D0=BE=D1=81=D1=83=D0=B4=D0=B0=D1=80=D1=81=D1=82=D0=B2= , =D1=87=D0=BB=D0=B5=D0=BD=D1=8B =D0=9F=D1=80=D0=B0=D0=B2=D0=B8=D1=82= =D0=B5=D0=BB=D1=8C=D1=81=D1=82=D0=B2=D0=B0 =D0=A0=D0=BE=D1=81=D1=81=D0= =B8=D0=B8, =D0=B7=D0=B2=D0=B5=D0=B7=D0=B4=D1=8B =D1=82=D0=B5=D0=BB=D0=B5= =D0=B2=D0=B8=D0=B4=D0=B5=D0=BD=D0=B8=D1=8F =D0=B8 =D1=88=D0=BE=D1=83-=D0= =B1=D0=B8=D0=B7=D0=BD=D0=B5=D1=81=D0=B0, =D0=BF=D1=80=D0=B5=D0=B7=D0=B8= =D0=B4=D0=B5=D0=BD=D1=82 =D1=80=D0=B5=D1=81=D0=BF=D1=83=D0=B1=D0=BB=D0= =B8=D0=BA=D0=B8 =D0=90=D1=80=D0=BC=D0=B5=D0=BD=D0=B8=D1=8F =D0=A1=D0=B5= =D1=80=D0=B6 =D0=A1=D0=B0=D1=80=D0=B3=D0=BE=D1=81=D1=8F=D0=BD, =D0=BF=D1= =80=D0=B5=D0=B7=D0=B8=D0=B4=D0=B5=D0=BD=D1=82 =D1=80=D0=B5=D1=81=D0=BF= =D1=83=D0=B1=D0=BB=D0=B8=D0=BA=D0=B8 =D0=AE=D0=B6=D0=BD=D0=B0=D1=8F =D0= =9E=D1=81=D0=B5=D1=82=D0=B8=D1=8F =D0=AD=D0=B4=D1=83=D0=B0=D1=80=D0=B4= =D0=9A=D0=B0=D0=BA=D0=BE=D0=B9=D1=82=D1=8B, =D0=BF=D1=80=D0=B5=D0=B7=D0= =B8=D0=B4=D0=B5=D0=BD=D1=82 =D0=9A=D0=B0=D0=B7=D0=B0=D1=85=D1=81=D1=82= =D0=B0=D0=BD=D0=B0 =D0=9D=D1=83=D1=80=D1=81=D1=83=D0=BB=D1=82=D0=B0=D0= =BD =D0=9D=D0=B0=D0=B7=D0=B0=D1=80=D0=B1=D0=B0=D0=B5=D0=B2, =D0=BF=D1=80= =D0=B5=D0=B7=D0=B8=D0=B4=D0=B5=D0=BD=D1=82 =D0=99=D0=B5=D0=BC=D0=B5=D0= =BD=D0=B0 =D0=90=D0=BB=D0=B8 =D0=90=D0=B1=D0=B4=D0=B0=D0=BB=D0=BB=D0=B0= =D0=A1=D0=B0=D0=BB=D0=B5=D1=85, =D0=BB=D0=B8=D0=B4=D0=B5=D1=80 =D0=BF= =D0=B0=D1=80=D1=82=D0=B8=D0=B8 =D0=9B=D0=94=D0=9F=D0=A0, =D0=B2=D0=B8=D1= =86=D0=B5-=D1=81=D0=BF=D0=B8=D0=BA=D0=B5=D1=80 =D0=93=D0=BE=D1=81=D0=B4= =D1=83=D0=BC=D1=8B =D0=92=D0=BB=D0=B0=D0=B4=D0=B8=D0=BC=D0=B8=D1=80 =D0= =96=D0=B8=D1=80=D0=B8=D0=BD=D0=BE=D0=B2=D1=81=D0=BA=D0=B8=D0=B9, =D0=BF= =D1=80=D0=B5=D0=B7=D0=B8=D0=B4=D0=B5=D0=BD=D1=82 =D1=84=D0=B5=D0=B4=D0= =B5=D1=80=D0=B0=D1=86=D0=B8=D0=B8 =D1=85=D0=BE=D0=BA=D0=BA=D0=B5=D1=8F= =D0=A0=D0=BE=D1=81=D1=81=D0=B8=D0=B8 =D0=92=D0=BB=D0=B0=D0=B4=D0=B8=D1= =81=D0=BB=D0=B0=D0=B2 =D0=A2=D1=80=D0=B5=D1=82=D1=8C=D1=8F=D0=BA =D0=B8= =D1=81=D0=BE=D1=82=D0=BD=D0=B8 =D1=82=D0=BE=D0=BF-=D0=BC=D0=B5=D0=BD= =D0=B5=D0=B4=D0=B6=D0=B5=D1=80=D0=BE=D0=B2 =D0=BA=D1=80=D1=83=D0=BF=D0= =BD=D0=B5=D0=B9=D1=88=D0=B8=D1=85 =D1=80=D0=BE=D1=81=D1=81=D0=B8=D0=B9= =D1=81=D0=BA=D0=B8=D1=85 =D0=B8 =D0=B7=D0=B0=D1=80=D1=83=D0=B1=D0=B5=D0= =B6=D0=BD=D1=8B=D1=85 =D0=BA=D0=BE=D0=BC=D0=BF=D0=B0=D0=BD=D0=B8=D0=B9= =2E =20 =D0=9A=D0=BE=D1=81=D1=82=D1=8E=D0=BC =D0=BC=D0=BE=D0=B6=D0=B5=D1=82 =D0= =BC=D0=BD=D0=BE=D0=B3=D0=BE=D0=B5 =D1=81=D0=BA=D0=B0=D0=B7=D0=B0=D1=82= =D1=8C =D0=BE =D1=81=D0=B2=D0=BE=D0=B5=D0=BC =D0=BE=D0=B1=D0=BB=D0=B0=D0= =B4=D0=B0=D1=82=D0=B5=D0=BB=D0=B5. =D0=9E=D0=BD =D0=BE=D1=82=D1=80=D0=B0= =D0=B6=D0=B0=D0=B5=D1=82 =D0=B5=D0=B3=D0=BE =D1=81=D1=82=D0=B0=D1=82=D1= =83=D1=81, =D1=81=D1=82=D0=B8=D0=BB=D1=8C, =D0=BF=D1=80=D0=BE=D1=84=D0= =B5=D1=81=D1=81=D0=B8=D0=BE=D0=BD=D0=B0=D0=BB=D1=8C=D0=BD=D1=83=D1=8E = =D0=BF=D1=80=D0=B8=D0=BD=D0=B0=D0=B4=D0=BB=D0=B5=D0=B6=D0=BD=D0=BE=D1=81= =D1=82=D1=8C =D0=B8 =D0=B4=D0=B0=D0=B6=D0=B5 =D1=85=D0=B0=D1=80=D0=B0=D0= =BA=D1=82=D0=B5=D1=80. =D0=9F=D0=BE=D1=8D=D1=82=D0=BE=D0=BC=D1=83 =D0=BA= =D0=B0=D0=B6=D0=B4=D1=8B=D0=B9 =D1=83=D1=81=D0=BF=D0=B5=D1=88=D0=BD=D1= =8B=D0=B9 =D1=87=D0=B5=D0=BB=D0=BE=D0=B2=D0=B5=D0=BA =D0=B4=D0=BE=D1=81= =D1=82=D0=BE=D0=B8=D0=BD =D0=B8=D0=B4=D0=B5=D0=B0=D0=BB=D1=8C=D0=BD=D0= =BE =D1=81=D1=88=D0=B8=D1=82=D0=BE=D0=B3=D0=BE =D0=BA=D0=BE=D0=BC=D0=BF= =D0=BB=D0=B5=D0=BA=D1=82=D0=B0, =D0=B2=D1=8B=D0=BF=D0=BE=D0=BB=D0=BD=D0= =B5=D0=BD=D0=BD=D0=BE=D0=B3=D0=BE =D0=BF=D0=BE =D1=83=D0=BD=D0=B8=D0=BA= =D0=B0=D0=BB=D1=8C=D0=BD=D1=8B=D0=BC =D0=BC=D0=B5=D1=80=D0=BA=D0=B0=D0= =BC.=20 =20 =D0=9A =D1=82=D0=BE=D0=BC=D1=83 =D0=B6=D0=B5, =D0=BF=D0=BE =D0=B4=D0=B0= =D0=BD=D0=BD=D1=8B=D0=BC =D1=80=D0=B5=D0=B9=D1=82=D0=B8=D0=BD=D0=B3=D0= =B0 askmen.com, =D0=BA=D0=BE=D0=BC=D0=BF=D0=B0=D0=BD=D0=B8=D1=8F =C2=AB= =D0=98=D0=BC=D0=BF=D0=B5=D1=80=D0=B0=D1=82=D0=BE=D1=80=D1=81=D0=BA=D0=B8= =D0=B9 =D0=9F=D0=BE=D1=80=D1=82=D0=BD=D0=BE=D0=B9=C2=BB =D1=8F=D0=B2=D0= =BB=D1=8F=D0=B5=D1=82=D1=81=D1=8F =D0=BE=D0=B4=D0=BD=D0=BE=D0=B9 =D0=B8= =D0=B7 10 =D1=81=D0=B0=D0=BC=D1=8B=D1=85 =D0=BB=D1=83=D1=87=D1=88=D0=B8= =D1=85 =D0=BF=D0=BE=D1=80=D1=82=D0=BD=D1=8B=D1=85 =D0=B2 =D0=BC=D0=B8=D1= =80=D0=B5. =D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC, =D0=9D=D0=B8=D1=80=D0=B0=D0=B4=D0=B6 =D0=A5=D0=B5=D0=BC=D0=BD=D0=B0=D0= =BD=D0=B8 =D0=9F=D0=BE=D1=80=D1=82=D0=BD=D0=BE=D0=B9 =D0=A2=D0=B5=D0=BB=D0=B5=D1=84=D0=BE=D0=BD: +7(926)2732490=20 =D0=90=D0=B4=D1=80=D0=B5=D1=81: =D0=B3=D0=BE=D1=81=D1=82=D0=B8=D0=BD=D0= =B8=D1=86=D0=B5 "=D0=9E=D0=BA=D0=B0" =D0=B3. =D0=9D.=D0=9D=D0=BE=D0=B2=D0=B3=D0=BE=D1=80=D0=BE=D0=B4, =D0=BF= =D1=80. =D0=93=D0=B0=D0=B3=D0=B0=D1=80=D0=B8=D0=BD=D0=B0, =D0=B4.27 nizhniynovgorod@mytailor.ru =20 =20 =20 =D0=9C=D0=BE=D1=81=D0=BA=D0=B2=D0=B0, =D0=93=D0=BE=D1=81=D1=82=D0=B8=D0= =BD=D1=8B=D0=B9 =D0=94=D0=B2=D0=BE=D1=80, =D0=A0=D1=8B=D0=B1=D0=BD=D1=8B= =D0=B9 =D0=BF=D0=B5=D1=80., =D0=B4. 2, =D1=81=D0=B5=D0=BA=D1=86=D0=B8=D1= =8F 130-132 =D0=A2=D0=B5=D0=BB=D0=B5=D1=84=D0=BE=D0=BD: + 7 (495) 232 1441, e-mail= : clients@mytailor.ru=20 =D0=95=D1=81=D0=BB=D0=B8 =D0=B2=D1=8B =D0=BD=D0=B5 =D1=85=D0=BE=D1=82=D0= =B8=D1=82=D0=B5 =D0=B1=D0=BE=D0=BB=D1=8C=D1=88=D0=B5 =D0=BF=D0=BE=D0=BB= =D1=83=D1=87=D0=B0=D1=82=D1=8C =D1=80=D0=B0=D1=81=D1=81=D1=8B=D0=BB=D0= =BA=D0=B8 =D0=BE=D1=82 =D0=BD=D0=B0=D1=81, =D0=BD=D0=B0=D0=B6=D0=BC=D0= =B8=D1=82=D0=B5 =D0=B7=D0=B4=D0=B5=D1=81=D1=8C. http://mytailor.ru=20 =20 From owner-freebsd-arch@FreeBSD.ORG Fri Oct 12 16:04:31 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 ADC6F937 for ; Fri, 12 Oct 2012 16:04:31 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 71EBA8FC17 for ; Fri, 12 Oct 2012 16:04:31 +0000 (UTC) Received: from marcelm-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q9CG4OZs064174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 12 Oct 2012 09:04:24 -0700 (PDT) (envelope-from marcel@xcllnt.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: mmap and resource limits From: Marcel Moolenaar In-Reply-To: <83AE27A6-C844-4720-99E7-A12106F77227@xcllnt.net> Date: Fri, 12 Oct 2012 09:04:19 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <83AE27A6-C844-4720-99E7-A12106F77227@xcllnt.net> To: "freebsd-arch@freebsd.org Arch" X-Mailer: Apple Mail (2.1499) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 16:04:31 -0000 On Oct 8, 2012, at 10:40 AM, Marcel Moolenaar wrote: > All, > > What's the progress of mmap(2) doing resource accounting and > it respecting resource limits? *silence* Ok, so no new progress. We're still not doing it and we don't have an idea of how we want to do it if or when we're going to want to do it. Consequently: we still need brk()/sbrk(). Correct assessment? -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Fri Oct 12 16:25:41 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 3B2C1195 for ; Fri, 12 Oct 2012 16:25:41 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id EE08D8FC1A for ; Fri, 12 Oct 2012 16:25:40 +0000 (UTC) Received: from marcelm-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q9CGPcLd064464 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Oct 2012 09:25:40 -0700 (PDT) (envelope-from marcel@xcllnt.net) From: Marcel Moolenaar Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Behavior of madvise(MADV_FREE) Date: Fri, 12 Oct 2012 09:25:34 -0700 Message-Id: <9FEBC10C-C453-41BE-8829-34E830585E90@xcllnt.net> To: "freebsd-arch@freebsd.org Arch" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: Tim LaBerge , Alan Cox X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 16:25:41 -0000 All, Juniper has been intrigued for a while about the beahviour of madvise(MADV_FREE). Let me give a bit of context before asking questions: 1. We have an important daemon that needs lots of memory. It uses sbrk()/brk() to extend its address space and uses madvise(MADV_FREE) to inform the kernel when a chunk of memory is effectively unused (the chunk is first zeroed). 2. Most of the time memory usage of the daemon is pretty stable, but under certain conditions it can spike, after which it drops back to a new stability point (either higher or lower). 3. Obviously the daemon is not the only component in the system, so whatever it doesn't need we very likely need somewhere else -- badly in some cases, so we do like immediate recycling then. Now on to the questions: 1. madvise(MADV_FREE) marks the pages as clean and moves them to the inactive queue. Why isn't the reference state cleared on either the page or the TLB? 2. Why aren't the pages moved to the cache queue in the first place? 3. What would be the impact or consequence of changing the behaviour of madvise(MADV_FREE) to mark the page as clean and unreferenced and have the page moved to the cache queue (or free queue even)? Ad 1: When the system is under memory pressure, the pageout daemon scans the inactive queue in order to try to move pages to the cache or free queue. With the MADV_FREE'd pages still having PG_REFERENCE or the underlying TLBs still having the access flag set, these pages actually get bumped to the active queue. Ad 2: MADV_DONTNEED is there to signal that the pages contain valid data, but that the page is not needed right now. Using this, pages get moved to the inactive queue. That makes sense. But MADV_FREE signals that there's no valid data anymore and that the page may be demand zeroed on next reference. The page is not inactive. It's free. If the paged was zeroed before calling MADV_FREE, the page really caches contents that that can be recreated later (the demand zero). Thanks, -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Fri Oct 12 17:13:53 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 0C0C7337 for ; Fri, 12 Oct 2012 17:13:53 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id B5C408FC12 for ; Fri, 12 Oct 2012 17:13:51 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 7AA3E3B080; Fri, 12 Oct 2012 17:13:42 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q9CHDfrQ004836; Fri, 12 Oct 2012 17:13:41 GMT (envelope-from phk@phk.freebsd.dk) To: Marcel Moolenaar Subject: Re: Behavior of madvise(MADV_FREE) In-reply-to: <9FEBC10C-C453-41BE-8829-34E830585E90@xcllnt.net> From: "Poul-Henning Kamp" References: <9FEBC10C-C453-41BE-8829-34E830585E90@xcllnt.net> Date: Fri, 12 Oct 2012 17:13:41 +0000 Message-ID: <4835.1350062021@critter.freebsd.dk> Cc: Tim LaBerge , Alan Cox , "freebsd-arch@freebsd.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 17:13:53 -0000 -------- In message <9FEBC10C-C453-41BE-8829-34E830585E90@xcllnt.net>, Marcel Moolenaar writes: >Now on to the questions: >1. madvise(MADV_FREE) marks the pages as clean and moves > them to the inactive queue. You can blame me for MADV_FREE, I nagged dyson into adding it for phkmalloc back when 16meg RAM cost a fortune. The main point of MADV_FREE when was to prevent a page-out of a dirty page, when the actual bits in the page were discarded from the applications point of view. The idea was for it to be a very fast operation, which would (potentially) save two disk operations, and the implementation simply washed the dirty bits away. (I think a later modification added further VM-wizardry to retain the allocated paging area, while avoiding the page-in in the case the pages were stolen.) The mapping were left alone, because it was estimated and measured that there were a high frequency of mapping reuse, in particular in the WorldStone where multiple passes of GCC competed for physical memory. The reference bit were left alone to not disturb the perceived/ measured VM-footprint of the process. I seem to recall that we experimented with a more aggressive version which severed the mapping and sent the page to pre-zeroing but the benchmarks showed too much overhead in the common case and too little gain in the relevant scenario. The name was clearly a mistake, but MADV_CLEAN would have been worse, and none of us had any other ideas at the time. Today I would have called it MADV_GARBAGE or MADV_RECYCLE. Given that paging anonymous pages to disk is not a major activity and unlikely to ever become a performance bottleneck again, it may make good sense to let MADV_FREE make the pages more appetizing for the rest of the system. But all things considered, I would advocate implementing MADV_RECYCLE for that, we need more nuance and expressability in madvice(2) and MADV_RECYCLE would be a good addition in its own right. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Oct 12 17:37:54 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 58750D10 for ; Fri, 12 Oct 2012 17:37:54 +0000 (UTC) (envelope-from bounce@mailconnect.info) Received: from host.dewanaysaray.in (host.dewanaysaray.in [64.120.228.10]) by mx1.freebsd.org (Postfix) with ESMTP id F27268FC0C for ; Fri, 12 Oct 2012 17:37:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mailconnect.info; s=default; h=Content-Transfer-Encoding:Content-Type:List-Unsubscribe:MIME-Version:Reply-To:From:Date:Message-ID:Subject:To; bh=XBcT0Pl4sKtbY9cIm1bKwZjZoPJKymbrhb74vBnWIO0=; b=vIxoIppfpgYypq1phRcByLo4yyoOLKjbBbMxIRt3C4SwCaTYIYYW/zMCrdI5DmQrP5AZLSK2ZKiV/RrQmkC61Rw0aQBMkznMEWCF6GkTX+R5Wn8s27vAO4HJgbQw2nyR; Received: from localhost ([127.0.0.1]:42234 helo=mailconnect.info) by host.dewanaysaray.in with esmtpa (Exim 4.80) (envelope-from ) id 1TMjBH-0006OQ-QQ for freebsd-arch@freebsd.org; Fri, 12 Oct 2012 13:37:51 -0400 To: freebsd-arch@freebsd.org Subject: Less belly fat before Christmas... Message-ID: <604c573c54298545f635a8f7754c2a9c@mailconnect.info> Date: Fri, 12 Oct 2012 12:23:54 -0400 From: "Steve Smith" MIME-Version: 1.0 X-Mailer-LID: 7 X-Mailer-RecptId: 1191092 X-Mailer-SID: 18 X-Mailer-Sent-By: 3 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.dewanaysaray.in X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - mailconnect.info X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: info@mailconnect.info List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 17:37:54 -0000 I bet you've asked the question why is belly fat so easily gained yet so hard to lose. It just seems unfair doesn't it? Well there is a reason. This short video will introduce you to techniques that reduce belly fat 9 times faster to look great before Christmas. WATCH VIDEO NOW> http://tinyurl.com/98tkorx ------------------------------------------------------------- Let's be honest, obviously the conventional methods you have been trying up to this point didn't work. The truth about belly fat is simply that it behaves in a different manner, and more importantly there are 3 HEALTHY foods that actually INCREASES abdominal fat which you should absolutely avoid! When it comes to abdominal fat there are things you should understand first and the truth is although it's a bit shocking, it really is surprisingly simple. WATCH NOW> http://tinyurl.com/98tkorx You can use this to get fast results for Christmas and also in the long run to maintain your belly fat. Everybody in any shape (good or bad) can benefit from understand abdominal fat behavior. Please enjoy the presentation (you will need sound)! Best Regards Steve Smith E-mail Disclaimer: The information transmitted is intended only for the person or entity to which it is addressed and may contain privileged material. If you received this email accidently we do apologies and you will be able to have your email removed for future newsletters by following the procedure at the bottom of this paragraph. Any review, re transmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. Any information within this message is not necessarily the expressed view of the E-MAIL SENDER and the E-MAIL SENDER cannot be held liable in any way. The information, images, documents and views expressed in this e-mail are personal to the sender and do not expressly or implicitly represent official positions and policies . If you received this in error, please contact the sender and delete the material from any computer. Every effort has been made to accurately represent this product and it¹s potential. Even though this industry is one of the few where one can reduce abdominal fat in less than 31 days, there is no promise. All products carry a full refund option should you be unhappy for any reason. Examples in these materials are not to be interpreted as a promise of loss. Success is entirely dependent on the person using the product, ideas and techniques. Your level of success in attaining the results claimed in our materials depends on your ability to follow and time and effort you devote to the program. To unsubscribe to this list please click here here> http://mailconnect.info/int/unsubscribe.php?M=1191092&C=3e88abf04441ccbb1cfe7af0c05bc5ed&L=7&N=18 From owner-freebsd-arch@FreeBSD.ORG Fri Oct 12 17:38:34 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 49FD2EDA; Fri, 12 Oct 2012 17:38:34 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by mx1.freebsd.org (Postfix) with ESMTP id 8AC3E8FC08; Fri, 12 Oct 2012 17:38:32 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKUHhVj8lduav1CikdCBYiHYZg26NK2Oo4@postini.com; Fri, 12 Oct 2012 10:38:33 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 12 Oct 2012 10:36:31 -0700 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q9CHaUh79003; Fri, 12 Oct 2012 10:36:30 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 7097658094; Fri, 12 Oct 2012 10:36:30 -0700 (PDT) To: Subject: Re: Building environment using system headers instead of the in-tree headers In-Reply-To: <50736C5A.1000604@delphij.net> References: <50736C5A.1000604@delphij.net> Comments: In-reply-to: Xin Li message dated "Mon, 08 Oct 2012 17:14:18 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Fri, 12 Oct 2012 10:36:30 -0700 Message-ID: <20121012173630.7097658094@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain Cc: peter@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 17:38:34 -0000 On Mon, 08 Oct 2012 17:14:18 -0700, Xin Li writes: >As it turns out, this was caused by addition of xlocale functionality >on FreeBSD 9.1, which uses macros and expects some new functions found >in more recent FreeBSD releases. On the other hand, we do not pass >e.g. -I${.CURDIR}/../../include so the header is preferred than system >header. Ideally anything which needs to build for the "host" should be sufficiently portable/generic that it can build on *any* host. There are better ways to tackle this than sprinkling -I${.CURDIR}/../../include everywhere - which only addresses a small fraction of the issue anyway (src/include contains only a fraction of what ends up in /usr/include). I think many/most of these sorts of issues will be neatly addressed by the changes we are planning to introduce to the FreeBSD build. The build infrastructure should understand the difference b/w building for host and target, and the correct -I's added automatically. In the Junos build for example we have the notion of PURE_HOSTPROG. "yes" means the app can build cleanly using only the host env "no" means it needs to use headers (perhaps generated code etc) from the src tree and so picks up additional -I's. By default hostpog's use the host's libs, but that can be overridden when needed (eg. an ATF test being built for the host, but wants to link the lib from the src tree that it is trying to test). --sjg From owner-freebsd-arch@FreeBSD.ORG Fri Oct 12 17:43:24 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 6E6EE3FB for ; Fri, 12 Oct 2012 17:43:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 413AB8FC08 for ; Fri, 12 Oct 2012 17:43:24 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8CD31B918; Fri, 12 Oct 2012 13:43:23 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: mmap and resource limits Date: Fri, 12 Oct 2012 13:38:28 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <83AE27A6-C844-4720-99E7-A12106F77227@xcllnt.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201210121338.28956.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 12 Oct 2012 13:43:23 -0400 (EDT) Cc: Marcel Moolenaar X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 17:43:24 -0000 On Friday, October 12, 2012 12:04:19 pm Marcel Moolenaar wrote: > > On Oct 8, 2012, at 10:40 AM, Marcel Moolenaar wrote: > > > All, > > > > What's the progress of mmap(2) doing resource accounting and > > it respecting resource limits? > > *silence* > > Ok, so no new progress. We're still not doing it and we don't > have an idea of how we want to do it if or when we're going to > want to do it. Consequently: we still need brk()/sbrk(). > > Correct assessment? Well. You can use RLIMIT_AS, but that includes anything you map, not just malloc(). The problem is that even if you use sbrk() and rely on RLIMIT_DATA, any misbehaving app can just use mmap(MAP_ANON) or shm_open() to get around that. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Oct 12 17:59:01 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 9899381E for ; Fri, 12 Oct 2012 17:59:01 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh11.mail.rice.edu (mh11.mail.rice.edu [128.42.199.30]) by mx1.freebsd.org (Postfix) with ESMTP id 66FC68FC0A for ; Fri, 12 Oct 2012 17:59:01 +0000 (UTC) Received: from mh11.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh11.mail.rice.edu (Postfix) with ESMTP id 53FA44C0284; Fri, 12 Oct 2012 12:59:00 -0500 (CDT) Received: from mh11.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh11.mail.rice.edu (Postfix) with ESMTP id 508E04C0243; Fri, 12 Oct 2012 12:59:00 -0500 (CDT) X-Virus-Scanned: by amavis-2.7.0 at mh11.mail.rice.edu, auth channel Received: from mh11.mail.rice.edu ([127.0.0.1]) by mh11.mail.rice.edu (mh11.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id JHcAVbh5xiw9; Fri, 12 Oct 2012 12:59:00 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh11.mail.rice.edu (Postfix) with ESMTPSA id 90B1E4C024F; Fri, 12 Oct 2012 12:58:59 -0500 (CDT) Message-ID: <50785A62.5050603@rice.edu> Date: Fri, 12 Oct 2012 12:58:58 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: Marcel Moolenaar Subject: Re: Behavior of madvise(MADV_FREE) References: <9FEBC10C-C453-41BE-8829-34E830585E90@xcllnt.net> In-Reply-To: <9FEBC10C-C453-41BE-8829-34E830585E90@xcllnt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tim LaBerge , "freebsd-arch@freebsd.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 17:59:01 -0000 On 10/12/2012 11:25, Marcel Moolenaar wrote: > All, > > Juniper has been intrigued for a while about the beahviour > of madvise(MADV_FREE). Let me give a bit of context before > asking questions: > > 1. We have an important daemon that needs lots of memory. > It uses sbrk()/brk() to extend its address space and > uses madvise(MADV_FREE) to inform the kernel when a > chunk of memory is effectively unused (the chunk is > first zeroed). > 2. Most of the time memory usage of the daemon is pretty > stable, but under certain conditions it can spike, > after which it drops back to a new stability point > (either higher or lower). > 3. Obviously the daemon is not the only component in the > system, so whatever it doesn't need we very likely > need somewhere else -- badly in some cases, so we do > like immediate recycling then. > > Now on to the questions: > 1. madvise(MADV_FREE) marks the pages as clean and moves > them to the inactive queue. Why isn't the reference > state cleared on either the page or the TLB? It is, at least 31 out of 32 times that vm_page_dontneed() is called. From vm_page_dontneed(), which is called by madvise(MADV_FREE): /* * Clear any references to the page. Otherwise, the page daemon will * immediately reactivate the page. * * Perform the pmap_clear_reference() first. Otherwise, a concurrent * pmap operation, such as pmap_remove(), could clear a reference in * the pmap and set PGA_REFERENCED on the page before the * pmap_clear_reference() had completed. Consequently, the page would * appear referenced based upon an old reference that occurred before * this function ran. */ pmap_clear_reference(m); vm_page_aflag_clear(m, PGA_REFERENCED); > 2. Why aren't the pages moved to the cache queue in the > first place? Because this would make madvise(MADV_FREE) considerably more expensive, for example, the pages would have to be unmapped. Your situation may be different, but more often than not, people call madvise(MADV_FREE) when memory is plentiful, and there is no need to do anything. In other words, the page daemon isn't going to need to run anytime soon. For example, when madvise(MADV_FREE) is used in implementations of malloc() and free(), the vast majority of calls to madvise(MADV_FREE) are pointless. They are pointless in that soon after the madvise(MADV_FREE) call by the free() implementation, either (1) the application turns around and allocates more memory causing the MADV_FREE'd memory to be used once again or (2) the process terminates before the page daemon runs. Consequently, the implementation of madvise(MADV_FREE) does the minimal necessary work so that if memory does become scarce and the page daemon has to run, that the MADV_FREE'd pages are first in line for reclamation. > 3. What would be the impact or consequence of changing > the behaviour of madvise(MADV_FREE) to mark the page > as clean and unreferenced and have the page moved to > the cache queue (or free queue even)? > > Ad 1: > When the system is under memory pressure, the pageout > daemon scans the inactive queue in order to try to move > pages to the cache or free queue. With the MADV_FREE'd > pages still having PG_REFERENCE or the underlying TLBs > still having the access flag set, these pages actually > get bumped to the active queue. I don't see this in recent versions. Maybe this is a bug in the version you're looking at. Perhaps, a bug in your pmap_clear_reference()? > Ad 2: > MADV_DONTNEED is there to signal that the pages contain > valid data, but that the page is not needed right now. > Using this, pages get moved to the inactive queue. That > makes sense. But MADV_FREE signals that there's no valid > data anymore and that the page may be demand zeroed on > next reference. The page is not inactive. It's free. If > the paged was zeroed before calling MADV_FREE, the page > really caches contents that that can be recreated later > (the demand zero). There is also another way of looking at it. By leaving the pages allocated and mapped, you are saving time, i.e., CPU cycles, for the all to common case that the MADV_FREE'd pages are used again in the near future. It wouldn't be illogical to have to two variants of MADV_FREE. One for use by folks like yourself who can say definitively that the pages won't be accessed again and should really be freed, and the current implementation for more speculative uses like in the malloc() and free() implementation. Better yet, the second case would be replaced by a notification from the kernel to the process when memory is actually becoming scarce so that we won't waste cycles on any pointless madvise() calls by the process. Regards, Alan From owner-freebsd-arch@FreeBSD.ORG Fri Oct 12 18:23:33 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 DC3FF472 for ; Fri, 12 Oct 2012 18:23:32 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh11.mail.rice.edu (mh11.mail.rice.edu [128.42.199.30]) by mx1.freebsd.org (Postfix) with ESMTP id AA7BE8FC0A for ; Fri, 12 Oct 2012 18:23:32 +0000 (UTC) Received: from mh11.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh11.mail.rice.edu (Postfix) with ESMTP id 23F6D4C0275; Fri, 12 Oct 2012 13:23:32 -0500 (CDT) Received: from mh11.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh11.mail.rice.edu (Postfix) with ESMTP id 2262B4C0238; Fri, 12 Oct 2012 13:23:32 -0500 (CDT) X-Virus-Scanned: by amavis-2.7.0 at mh11.mail.rice.edu, auth channel Received: from mh11.mail.rice.edu ([127.0.0.1]) by mh11.mail.rice.edu (mh11.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id I4Mk7HQUInoc; Fri, 12 Oct 2012 13:23:32 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh11.mail.rice.edu (Postfix) with ESMTPSA id A39EF4C021B; Fri, 12 Oct 2012 13:23:31 -0500 (CDT) Message-ID: <50786023.1000206@rice.edu> Date: Fri, 12 Oct 2012 13:23:31 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: Poul-Henning Kamp Subject: Re: Behavior of madvise(MADV_FREE) References: <9FEBC10C-C453-41BE-8829-34E830585E90@xcllnt.net> <4835.1350062021@critter.freebsd.dk> In-Reply-To: <4835.1350062021@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tim LaBerge , "freebsd-arch@freebsd.org Arch" , Marcel Moolenaar X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 18:23:33 -0000 On 10/12/2012 12:13, Poul-Henning Kamp wrote: > -------- > In message<9FEBC10C-C453-41BE-8829-34E830585E90@xcllnt.net>, Marcel Moolenaar writes: > >> Now on to the questions: >> 1. madvise(MADV_FREE) marks the pages as clean and moves >> them to the inactive queue. > You can blame me for MADV_FREE, I nagged dyson into adding it for > phkmalloc back when 16meg RAM cost a fortune. > > The main point of MADV_FREE when was to prevent a page-out of a > dirty page, when the actual bits in the page were discarded from > the applications point of view. > > The idea was for it to be a very fast operation, which would > (potentially) save two disk operations, and the implementation > simply washed the dirty bits away. > > (I think a later modification added further VM-wizardry to retain > the allocated paging area, while avoiding the page-in in the case > the pages were stolen.) It would be more accurate to say that no action is taken to reclaim any previously allocated swap space, which is unlikely to exist anyway. > The mapping were left alone, because it was estimated and measured > that there were a high frequency of mapping reuse, in particular > in the WorldStone where multiple passes of GCC competed for physical > memory. The reference bit were left alone to not disturb the > perceived/ measured VM-footprint of the process. This last "bit" is dated. :-) We have long cleared the reference bit. > I seem to recall that we experimented with a more aggressive > version which severed the mapping and sent the page to pre-zeroing > but the benchmarks showed too much overhead in the common case > and too little gain in the relevant scenario. > > The name was clearly a mistake, but MADV_CLEAN would have been > worse, and none of us had any other ideas at the time. Today I > would have called it MADV_GARBAGE or MADV_RECYCLE. > > Given that paging anonymous pages to disk is not a major activity > and unlikely to ever become a performance bottleneck again, it may > make good sense to let MADV_FREE make the pages more appetizing > for the rest of the system. Given the way that madvise(MADV_FREE) is still used by malloc()/free(), any additional overhead would still be a pessimization most of the time. Over the years, I think you and I have both said that what we really need is the ability for the kernel to deliver an event to malloc()/free() when memory is trending toward scarcity. Applications could also use this to reduce the size of their internal caches. > But all things considered, I would advocate implementing MADV_RECYCLE > for that, we need more nuance and expressability in madvice(2) and > MADV_RECYCLE would be a good addition in its own right. Probably so. Alan From owner-freebsd-arch@FreeBSD.ORG Fri Oct 12 18:46:46 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 B11BDC95 for ; Fri, 12 Oct 2012 18:46:46 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 65B798FC1A for ; Fri, 12 Oct 2012 18:46:46 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id DB4713B080; Fri, 12 Oct 2012 18:46:43 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q9CIkg7B005512; Fri, 12 Oct 2012 18:46:42 GMT (envelope-from phk@phk.freebsd.dk) To: Alan Cox Subject: Re: Behavior of madvise(MADV_FREE) In-reply-to: <50786023.1000206@rice.edu> From: "Poul-Henning Kamp" References: <9FEBC10C-C453-41BE-8829-34E830585E90@xcllnt.net> <4835.1350062021@critter.freebsd.dk> <50786023.1000206@rice.edu> Date: Fri, 12 Oct 2012 18:46:42 +0000 Message-ID: <5511.1350067602@critter.freebsd.dk> Cc: Tim LaBerge , Marcel Moolenaar , "freebsd-arch@freebsd.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 18:46:46 -0000 -------- In message <50786023.1000206@rice.edu>, Alan Cox writes: >Given the way that madvise(MADV_FREE) is still used by malloc()/free(), >any additional overhead would still be a pessimization most of the >time. That would be my fear too. >Over the years, I think you and I have both said that what we >really need is the ability for the kernel to deliver an event to >malloc()/free() when memory is trending toward scarcity. I still think this would be a good idea, and I can only assume that the absense of this feature is due to Jason Evans failing in his malloc-maintainers duty of bugging the VM people for this feature at every conceiveable opportunity :-) That being said, my experience with Varnish does indicate that intelligent use of VM from userland is close to a lost case, in no small part because of the lack of a good API. If you can spare a student of sufficient quality, it might be a good assignment to design a new VM-API, relative to the current reality of things like malware attacks, "no-execute" bits etc. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Oct 12 20:54: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 D2F31D27 for ; Fri, 12 Oct 2012 20:54:27 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id AADF88FC18 for ; Fri, 12 Oct 2012 20:54:27 +0000 (UTC) Received: from marcelm-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q9CKsNfJ068081 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Oct 2012 13:54:25 -0700 (PDT) (envelope-from marcel@xcllnt.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Behavior of madvise(MADV_FREE) From: Marcel Moolenaar In-Reply-To: <4835.1350062021@critter.freebsd.dk> Date: Fri, 12 Oct 2012 13:54:18 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <9FEBC10C-C453-41BE-8829-34E830585E90@xcllnt.net> <4835.1350062021@critter.freebsd.dk> To: Poul-Henning Kamp X-Mailer: Apple Mail (2.1499) Cc: Tim LaBerge , Alan Cox , "freebsd-arch@freebsd.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 20:54:27 -0000 On Oct 12, 2012, at 10:13 AM, Poul-Henning Kamp wrote: >> Now on to the questions: >> 1. madvise(MADV_FREE) marks the pages as clean and moves >> them to the inactive queue. > The mapping were left alone, because it was estimated and measured > that there were a high frequency of mapping reuse, in particular > in the WorldStone where multiple passes of GCC competed for physical > memory. The reference bit were left alone to not disturb the > perceived/ measured VM-footprint of the process. Good info. Thanks. > Given that paging anonymous pages to disk is not a major activity > and unlikely to ever become a performance bottleneck again, it may > make good sense to let MADV_FREE make the pages more appetizing > for the rest of the system. > > But all things considered, I would advocate implementing MADV_RECYCLE > for that, we need more nuance and expressability in madvice(2) and > MADV_RECYCLE would be a good addition in its own right. Ok. I think Linux has MADV_REMOVE that roughly matches the semantics, so it's not "non-standard" to add more behaviours. BTW: MADV_DONTNEED in Linux seems to behave like MADV_FREE in FreeBSD -- at least according to the manpage. Which makes me wonder how standard madvise(2) is anyway. -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Fri Oct 12 20:55:30 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 980FDE10 for ; Fri, 12 Oct 2012 20:55:30 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 4C56A8FC14 for ; Fri, 12 Oct 2012 20:55:30 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 9EA433B772; Fri, 12 Oct 2012 20:55:28 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q9CKtSpe006069; Fri, 12 Oct 2012 20:55:28 GMT (envelope-from phk@phk.freebsd.dk) To: Marcel Moolenaar Subject: Re: Behavior of madvise(MADV_FREE) In-reply-to: From: "Poul-Henning Kamp" References: <9FEBC10C-C453-41BE-8829-34E830585E90@xcllnt.net> <4835.1350062021@critter.freebsd.dk> Date: Fri, 12 Oct 2012 20:55:28 +0000 Message-ID: <6068.1350075328@critter.freebsd.dk> Cc: Tim LaBerge , "freebsd-arch@freebsd.org Arch" , Alan Cox X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 20:55:30 -0000 -------- In message , Marcel Moolenaar writes: >BTW: MADV_DONTNEED in Linux seems to behave like MADV_FREE >in FreeBSD -- at least according to the manpage. Which makes >me wonder how standard madvise(2) is anyway. "Not at all" is how much standard it is. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Oct 12 21:00:29 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 DCC3EF65 for ; Fri, 12 Oct 2012 21:00:28 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id B0D6E8FC0C for ; Fri, 12 Oct 2012 21:00:28 +0000 (UTC) Received: from marcelm-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q9CL0PZM068231 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Oct 2012 14:00:27 -0700 (PDT) (envelope-from marcel@xcllnt.net) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Behavior of madvise(MADV_FREE) From: Marcel Moolenaar In-Reply-To: <50785A62.5050603@rice.edu> Date: Fri, 12 Oct 2012 14:00:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <186E5ECB-120E-4E49-96B4-485E2676C05F@xcllnt.net> References: <9FEBC10C-C453-41BE-8829-34E830585E90@xcllnt.net> <50785A62.5050603@rice.edu> To: Alan Cox X-Mailer: Apple Mail (2.1499) Cc: Tim LaBerge , "freebsd-arch@freebsd.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 21:00:29 -0000 On Oct 12, 2012, at 10:58 AM, Alan Cox wrote: >> Now on to the questions: >> 1. madvise(MADV_FREE) marks the pages as clean and moves >> them to the inactive queue. Why isn't the reference >> state cleared on either the page or the TLB? >=20 > It is, at least 31 out of 32 times that vm_page_dontneed() is called. = =46rom vm_page_dontneed(), which is called by madvise(MADV_FREE): >=20 > /* > * Clear any references to the page. Otherwise, the page = daemon will > * immediately reactivate the page. > * > * Perform the pmap_clear_reference() first. Otherwise, a = concurrent > * pmap operation, such as pmap_remove(), could clear a = reference in > * the pmap and set PGA_REFERENCED on the page before the > * pmap_clear_reference() had completed. Consequently, the = page would > * appear referenced based upon an old reference that occurred = before > * this function ran. > */ > pmap_clear_reference(m); > vm_page_aflag_clear(m, PGA_REFERENCED); Ah... I missed this. I didn't look in vm_page_dontneed() for this. I thought current FreeBSD behaved the same as 6.1-ish. >> 2. Why aren't the pages moved to the cache queue in the >> first place? >=20 > Because this would make madvise(MADV_FREE) considerably more = expensive, for example, the pages would have to be unmapped. Your = situation may be different, but more often than not, people call = madvise(MADV_FREE) when memory is plentiful, and there is no need to do = anything. In other words, the page daemon isn't going to need to run = anytime soon. For example, when madvise(MADV_FREE) is used in = implementations of malloc() and free(), the vast majority of calls to = madvise(MADV_FREE) are pointless. They are pointless in that soon after = the madvise(MADV_FREE) call by the free() implementation, either (1) the = application turns around and allocates more memory causing the = MADV_FREE'd memory to be used once again or (2) the process terminates = before the page daemon runs. Consequently, the implementation of = madvise(MADV_FREE) does the minimal necessary work so that if memory = does become scarce and the page daemon has to run, that the MADV_FREE'd = pages are first in line for reclamation. Understood. Thanks. >> Ad 2: >> MADV_DONTNEED is there to signal that the pages contain >> valid data, but that the page is not needed right now. >> Using this, pages get moved to the inactive queue. That >> makes sense. But MADV_FREE signals that there's no valid >> data anymore and that the page may be demand zeroed on >> next reference. The page is not inactive. It's free. If >> the paged was zeroed before calling MADV_FREE, the page >> really caches contents that that can be recreated later >> (the demand zero). >=20 > There is also another way of looking at it. By leaving the pages = allocated and mapped, you are saving time, i.e., CPU cycles, for the all = to common case that the MADV_FREE'd pages are used again in the near = future. >=20 > It wouldn't be illogical to have to two variants of MADV_FREE. One = for use by folks like yourself who can say definitively that the pages = won't be accessed again and should really be freed, and the current = implementation for more speculative uses like in the malloc() and free() = implementation. Better yet, the second case would be replaced by a = notification from the kernel to the process when memory is actually = becoming scarce so that we won't waste cycles on any pointless madvise() = calls by the process. This aligns with phk@s suggestion of MADV_RECYCLE. We may want to play with this. --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Fri Oct 12 21:11:55 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 40EC7350; Fri, 12 Oct 2012 21:11:55 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 198DE8FC12; Fri, 12 Oct 2012 21:11:54 +0000 (UTC) Received: from marcelm-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q9CLBrgX068367 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Oct 2012 14:11:54 -0700 (PDT) (envelope-from marcel@xcllnt.net) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: mmap and resource limits From: Marcel Moolenaar In-Reply-To: <201210121338.28956.jhb@freebsd.org> Date: Fri, 12 Oct 2012 14:11:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8C8FEFC1-35CD-4104-B518-DA32A3EA242C@xcllnt.net> References: <83AE27A6-C844-4720-99E7-A12106F77227@xcllnt.net> <201210121338.28956.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1499) Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 21:11:55 -0000 On Oct 12, 2012, at 10:38 AM, John Baldwin wrote: > On Friday, October 12, 2012 12:04:19 pm Marcel Moolenaar wrote: >>=20 >> On Oct 8, 2012, at 10:40 AM, Marcel Moolenaar = wrote: >>=20 >>> All, >>>=20 >>> What's the progress of mmap(2) doing resource accounting and >>> it respecting resource limits? >>=20 >> *silence* >>=20 >> Ok, so no new progress. We're still not doing it and we don't >> have an idea of how we want to do it if or when we're going to >> want to do it. Consequently: we still need brk()/sbrk(). >>=20 >> Correct assessment? >=20 > Well. You can use RLIMIT_AS, but that includes anything you map, not = just=20 > malloc(). The problem is that even if you use sbrk() and rely on = RLIMIT_DATA,=20 > any misbehaving app can just use mmap(MAP_ANON) or shm_open() to get = around=20 > that. Wouldn't it be a good approach then to enforce RLIMIT_AS as the external (to the process) limit and define RLIMIT_DATA et al as internal (to the process) resources as a way to have the process put limits on particular types of memory and do so on a voluntary basis? I mean, RLIMIT_STACK is impossible to enforce in multi-threaded processes. RLIMIT_CODE is already convoluted by having R/O data in the same segment. RLIMIT_DATA... well... So, have processes give meaning to them in whatever way makes sense to the process and have the kernel limit it "FWIW"? Any thoughts on the best way for a process can tell the kernel how to treat a memory region (i.e. data, stack or code)? --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Fri Oct 12 21:21:09 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 0442B5D2 for ; Fri, 12 Oct 2012 21:21:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id CA60E8FC17 for ; Fri, 12 Oct 2012 21:21:08 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 343FEB918; Fri, 12 Oct 2012 17:21:08 -0400 (EDT) From: John Baldwin To: Marcel Moolenaar Subject: Re: mmap and resource limits Date: Fri, 12 Oct 2012 17:19:40 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <83AE27A6-C844-4720-99E7-A12106F77227@xcllnt.net> <201210121338.28956.jhb@freebsd.org> <8C8FEFC1-35CD-4104-B518-DA32A3EA242C@xcllnt.net> In-Reply-To: <8C8FEFC1-35CD-4104-B518-DA32A3EA242C@xcllnt.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201210121719.40171.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 12 Oct 2012 17:21:08 -0400 (EDT) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 21:21:09 -0000 On Friday, October 12, 2012 5:11:48 pm Marcel Moolenaar wrote: > > On Oct 12, 2012, at 10:38 AM, John Baldwin wrote: > > > On Friday, October 12, 2012 12:04:19 pm Marcel Moolenaar wrote: > >> > >> On Oct 8, 2012, at 10:40 AM, Marcel Moolenaar wrote: > >> > >>> All, > >>> > >>> What's the progress of mmap(2) doing resource accounting and > >>> it respecting resource limits? > >> > >> *silence* > >> > >> Ok, so no new progress. We're still not doing it and we don't > >> have an idea of how we want to do it if or when we're going to > >> want to do it. Consequently: we still need brk()/sbrk(). > >> > >> Correct assessment? > > > > Well. You can use RLIMIT_AS, but that includes anything you map, not just > > malloc(). The problem is that even if you use sbrk() and rely on RLIMIT_DATA, > > any misbehaving app can just use mmap(MAP_ANON) or shm_open() to get around > > that. > > Wouldn't it be a good approach then to enforce RLIMIT_AS as the > external (to the process) limit and define RLIMIT_DATA et al > as internal (to the process) resources as a way to have the > process put limits on particular types of memory and do so on > a voluntary basis? > > I mean, RLIMIT_STACK is impossible to enforce in multi-threaded > processes. RLIMIT_CODE is already convoluted by having R/O data > in the same segment. RLIMIT_DATA... well... > > So, have processes give meaning to them in whatever way makes > sense to the process and have the kernel limit it "FWIW"? > > Any thoughts on the best way for a process can tell the kernel > how to treat a memory region (i.e. data, stack or code)? The one thought I had was to have a RLIMIT_ANON perhaps which limits the amount of MAP_ANON memory a process uses. This would be mostly equivalent to RLIMIT_DATA. Note that rtld uses its own private pool of MAP_ANON pages for an internal malloc, so that would be part of this limit as well. This limit would be checked at mmap() time, so things like anonymous pages due to COW mappings on MAP_PRIVATE mappings wouldn't count against it. However, to catch programs with a memory leak using a MAP_ANON-backed malloc() similar to RLIMIT_DATA it would probably work. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Oct 12 22:15:06 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 78172ECD for ; Fri, 12 Oct 2012 22:15:06 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from canonware.com (canonware.com [204.109.63.53]) by mx1.freebsd.org (Postfix) with ESMTP id 51ED98FC14 for ; Fri, 12 Oct 2012 22:15:06 +0000 (UTC) Received: from jemac.thefacebook.com (unknown [173.252.71.6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by canonware.com (Postfix) with ESMTPSA id 3B35B2842D; Fri, 12 Oct 2012 15:05:24 -0700 (PDT) Subject: Re: Behavior of madvise(MADV_FREE) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Jason Evans In-Reply-To: Date: Fri, 12 Oct 2012 15:05:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9FEBC10C-C453-41BE-8829-34E830585E90@xcllnt.net> <4835.1350062021@critter.freebsd.dk> To: Marcel Moolenaar X-Mailer: Apple Mail (2.1283) Cc: Poul-Henning Kamp , "freebsd-arch@freebsd.org Arch" , Tim LaBerge , Alan Cox X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 22:15:06 -0000 On Oct 12, 2012, at 1:54 PM, Marcel Moolenaar wrote: > BTW: MADV_DONTNEED in Linux seems to behave like MADV_FREE > in FreeBSD -- at least according to the manpage. Which makes > me wonder how standard madvise(2) is anyway. MADV_DONTNEED on Linux immediately dissociates the physical page from = the VM mapping, such that subsequent access results in a zero-filled = page being soft-faulted into place. MADV_FREE is *way* nicer than MADV_DONTNEED in the context of malloc. = jemalloc has a really discouraging amount of complexity that is directly = a result of working around the performance overhead of MADV_DONTNEED. Jason= From owner-freebsd-arch@FreeBSD.ORG Fri Oct 12 22:15:44 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 7762DF9F; Fri, 12 Oct 2012 22:15:44 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107]) by mx1.freebsd.org (Postfix) with ESMTP id 104FE8FC0A; Fri, 12 Oct 2012 22:15:43 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 942561203C1; Sat, 13 Oct 2012 00:15:38 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 7EFCD2848C; Sat, 13 Oct 2012 00:15:38 +0200 (CEST) Date: Sat, 13 Oct 2012 00:15:38 +0200 From: Jilles Tjoelker To: John Baldwin Subject: Re: mmap and resource limits Message-ID: <20121012221538.GA96422@stack.nl> References: <83AE27A6-C844-4720-99E7-A12106F77227@xcllnt.net> <201210121338.28956.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201210121338.28956.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Marcel Moolenaar , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 22:15:44 -0000 On Fri, Oct 12, 2012 at 01:38:28PM -0400, John Baldwin wrote: > On Friday, October 12, 2012 12:04:19 pm Marcel Moolenaar wrote: > > On Oct 8, 2012, at 10:40 AM, Marcel Moolenaar wrote: > > > What's the progress of mmap(2) doing resource accounting and > > > it respecting resource limits? > > *silence* > > Ok, so no new progress. We're still not doing it and we don't > > have an idea of how we want to do it if or when we're going to > > want to do it. Consequently: we still need brk()/sbrk(). > > Correct assessment? > Well. You can use RLIMIT_AS, but that includes anything you map, not > just malloc(). This is effective for many applications. I have found it particularly useful against runaway memory leaks in applications moved from 32-bit to 64-bit systems. > The problem is that even if you use sbrk() and rely on RLIMIT_DATA, > any misbehaving app can just use mmap(MAP_ANON) or shm_open() to get > around that. As of 8.0 it is possible to enable swap accounting to limit anonymous memory. This uses the vm.overcommit sysctl and RLIMIT_SWAP rlimit described in tuning(7). For example: # sysctl vm.overcommit=2 $ ulimit -w 100000 The rlimit limits the total for the UID (much like RLIMIT_NPROC, RLIMIT_SBSIZE and RLIMIT_NPTS). -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Sat Oct 13 19:16:01 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 F40D9788; Sat, 13 Oct 2012 19:16:00 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id A8B888FC08; Sat, 13 Oct 2012 19:16:00 +0000 (UTC) Received: from pool-96-250-5-62.nycmny.fios.verizon.net ([96.250.5.62]:60073 helo=minion.home) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TN7Bo-0005JZ-2M; Sat, 13 Oct 2012 15:16:00 -0400 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program From: George Neville-Neil In-Reply-To: <127FA63D-8EEE-4616-AE1E-C39469DDCC6A@xcllnt.net> Date: Sat, 13 Oct 2012 15:15:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1340AB5D-F824-4E7D-9D6C-F7E5489AE870@neville-neil.com> References: <201210020750.23358.jhb@freebsd.org> <201210021037.27762.jhb@freebsd.org> <127FA63D-8EEE-4616-AE1E-C39469DDCC6A@xcllnt.net> To: Marcel Moolenaar X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: Garrett Cooper , freebsd-hackers@freebsd.org, "Simon J. Gerraty" , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 19:16:01 -0000 On Oct 8, 2012, at 12:11 , Marcel Moolenaar wrote: >=20 > On Oct 4, 2012, at 9:42 AM, Garrett Cooper wrote: >>>> Both parties (Isilon/Juniper) are converging on the ATF porting = work >>>> that Giorgos/myself have done after talking at the FreeBSD = Foundation >>>> meet-n-greet. I have contributed all of the patches that I have = other >>>> to marcel for feedback. >>>=20 >>> This is very non-obvious to the public at large (e.g. there was no = public >>> response to one group's inquiry about the second ATF import for = example). >>> Also, given that you had no idea that sgf@ and obrien@ were working = on >>> importing NetBSD's bmake as a prerequisite for ATF, it seems that = whatever >>> discussions were held were not very detailed at best. I think it = would be >>> good to have the various folks working on ATF to at least summarize = the >>> current state of things and sketch out some sort of plan or roadmap = for future >>> work in a public forum (such as atf@, though a summary mail would be = quite >>> appropriate for arch@). >>=20 >> I'm in part to blame for this. There was some discussion -- but not = at >> length; unfortunately no one from Juniper was present at the meet and >> greet; the information I got was second hand; I didn't follow up to >> figure out the exact details / clarify what I had in mind with the >> appropriate parties. >=20 > Hang on. I want in on the blame part! :-) >=20 > Seriously: no-one is really to blame as far as I can see. We just had > two independent efforts (ATF & bmake) and there was no indication that > one would be greatly benefitted from the other. At least not to the > point of creating a dependency. >=20 > I just committed the bmake bits. It not only adds bmake to the build, > but also includes the changes necessary to use bmake. >=20 > With that in place it's easier to decide whether we want the = dependency > or not. >=20 > Before we can switch permanently to bmake, we need to do the following > first: > 1. Request an EXP ports build with bmake as make(1). This should tell > us the "damage" of switching to bmake for ports. > 2. In parallel with 1: build www & docs with bmake and assess the > damage > 3. Fix all the damage >=20 > Then: >=20 > 4. Switch. >=20 > It could be a while (many weeks) before we get to 4, so the question > really is whether the people working on ATF are willing and able to > build and install FreeBSD using WITH_BMAKE? >=20 I think that's a small price to pay for getting going with the ATF stuff now rather than in 4 weeks. What's the right way to do this now with HEAD? Best, George From owner-freebsd-arch@FreeBSD.ORG Sat Oct 13 20:15:37 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 6E715BCA; Sat, 13 Oct 2012 20:15:37 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by mx1.freebsd.org (Postfix) with ESMTP id D6BBF8FC0C; Sat, 13 Oct 2012 20:15:36 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKUHnL4vuHMYYtf2/iwemqs81nA5iY7LWn@postini.com; Sat, 13 Oct 2012 13:15:37 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 13 Oct 2012 13:13:30 -0700 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q9DKDUh83856; Sat, 13 Oct 2012 13:13:30 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 68EBB58094; Sat, 13 Oct 2012 13:13:30 -0700 (PDT) To: George Neville-Neil Subject: Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program In-Reply-To: <1340AB5D-F824-4E7D-9D6C-F7E5489AE870@neville-neil.com> References: <201210020750.23358.jhb@freebsd.org> <201210021037.27762.jhb@freebsd.org> <127FA63D-8EEE-4616-AE1E-C39469DDCC6A@xcllnt.net> <1340AB5D-F824-4E7D-9D6C-F7E5489AE870@neville-neil.com> Comments: In-reply-to: George Neville-Neil message dated "Sat, 13 Oct 2012 15:15:59 -0400." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Sat, 13 Oct 2012 13:13:30 -0700 Message-ID: <20121013201330.68EBB58094@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain Cc: Garrett Cooper , freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org, Marcel Moolenaar X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 20:15:37 -0000 On Sat, 13 Oct 2012 15:15:59 -0400, George Neville-Neil writes: >> It could be a while (many weeks) before we get to 4, so the question >> really is whether the people working on ATF are willing and able to >> build and install FreeBSD using WITH_BMAKE? >>=20 > >I think that's a small price to pay for getting going with the ATF >stuff now rather than in 4 weeks. What's the right way to do this >now with HEAD? We can add bsd.progs.mk (if you have devel/bmake port installed you have it as /usr/local/share/mk/progs.mk) and atf.test.mk and people can just "go for it" ? From owner-freebsd-arch@FreeBSD.ORG Sat Oct 13 20:52:42 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 F3AA87BA; Sat, 13 Oct 2012 20:52:41 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id C63AC8FC14; Sat, 13 Oct 2012 20:52:41 +0000 (UTC) Received: from marcelm-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q9DKqdBr086942 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 13 Oct 2012 13:52:40 -0700 (PDT) (envelope-from marcel@xcllnt.net) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program From: Marcel Moolenaar In-Reply-To: <1340AB5D-F824-4E7D-9D6C-F7E5489AE870@neville-neil.com> Date: Sat, 13 Oct 2012 13:52:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201210020750.23358.jhb@freebsd.org> <201210021037.27762.jhb@freebsd.org> <127FA63D-8EEE-4616-AE1E-C39469DDCC6A@xcllnt.net> <1340AB5D-F824-4E7D-9D6C-F7E5489AE870@neville-neil.com> To: George Neville-Neil X-Mailer: Apple Mail (2.1499) Cc: Garrett Cooper , freebsd-hackers@freebsd.org, "Simon J. Gerraty" , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 20:52:42 -0000 On Oct 13, 2012, at 12:15 PM, George Neville-Neil = wrote: >=20 > I think that's a small price to pay for getting going with the ATF > stuff now rather than in 4 weeks. What's the right way to do this > now with HEAD? Set WITH_BMAKE=3Dyes in /etc/src.conf or /etc/make.conf and you're good to go. One caveat: manually rebuild and re-install usr.bin/bmake after the buildworld & installworld with WITH_BMAKE=3Dyes set. The one created as part of the buildworld has a bug due to being built by FreeBSD's make. A fix is known and will be committed soon, but until then, the manual step is needed. That's it... --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Sat Oct 13 22:37:11 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 002C62BA; Sat, 13 Oct 2012 22:37:10 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 97AFD8FC0C; Sat, 13 Oct 2012 22:37:10 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id wc20so5176500obb.13 for ; Sat, 13 Oct 2012 15:37:10 -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; bh=fmxPqBHeXKhnIVGRjFlZpQ3NcNpdYVC8PT/Dd0LdV+c=; b=UkxFa9IkbISyPnGpUhh7h1WHJ7BcmQAFw2F7ZWprPCqhMci33zIsuuZohlubX0U2Yu YJevPtd6OBBNDQehq3dG0DXquIYW71up+/krGcAF29xSSM+enLTt14iJ23sttI5GwIro e2pNHQ28v4jrKTkFfAL/nqh2USR74Pbyafl38CXlwKUuGbMLvGrarTXLQK8XEPNfnlEr 5/Ny+8SyzOO9qNWVkaSEEFcojEOSlVLFWem9uuJ7xhI/Z0X+p+SFVad4oJPVElPWRS/e ZPQ/8f0q4jmKtql9knO+YWKSBD08X73eGM7k2flhEd9nUlijA7k+XqRjF+3wIiZey+E0 14uA== MIME-Version: 1.0 Received: by 10.182.31.50 with SMTP id x18mr6317895obh.56.1350167830150; Sat, 13 Oct 2012 15:37:10 -0700 (PDT) Received: by 10.76.167.202 with HTTP; Sat, 13 Oct 2012 15:37:09 -0700 (PDT) In-Reply-To: <20121013201330.68EBB58094@chaos.jnpr.net> References: <201210020750.23358.jhb@freebsd.org> <201210021037.27762.jhb@freebsd.org> <127FA63D-8EEE-4616-AE1E-C39469DDCC6A@xcllnt.net> <1340AB5D-F824-4E7D-9D6C-F7E5489AE870@neville-neil.com> <20121013201330.68EBB58094@chaos.jnpr.net> Date: Sat, 13 Oct 2012 15:37:09 -0700 Message-ID: Subject: Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program From: Garrett Cooper To: "Simon J. Gerraty" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, George Neville-Neil , freebsd-arch@freebsd.org, Marcel Moolenaar X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 22:37:11 -0000 On Sat, Oct 13, 2012 at 1:13 PM, Simon J. Gerraty wrote: > > On Sat, 13 Oct 2012 15:15:59 -0400, George Neville-Neil writes: >>> It could be a while (many weeks) before we get to 4, so the question >>> really is whether the people working on ATF are willing and able to >>> build and install FreeBSD using WITH_BMAKE? >> >>I think that's a small price to pay for getting going with the ATF >>stuff now rather than in 4 weeks. What's the right way to do this >>now with HEAD? > > We can add bsd.progs.mk (if you have devel/bmake port installed you > have it as /usr/local/share/mk/progs.mk) > and atf.test.mk and people can just "go for it" ? As long as it can function sanely in a NetBSD-like manner and I can start writing tests, I don't mind... Thanks! -Garrett