Re: [PATCH] Fix kenv(1) output in w/respect to new boot loader variables

[Sergey Kandaurov]

On 28 December 2011 05:26, Devin Teske  wrote:
> D'Oh! Attached wrong (OLD; already applied) patch.
>
> Please find appropriate patch attached!

Hi.

I committed your patch to head as svn r228985.
Thank you!

>
>> -Original Message-
>> From: Devin Teske [mailto:devin.te...@fisglobal.com]
>> Sent: Tuesday, December 27, 2011 5:24 PM
>> To: 'freebsd-hackers@freebsd.org'
>> Cc: Garrett Cooper; devin.te...@fisglobal.com
>> Subject: [PATCH] Fix kenv(1) output in w/respect to new boot loader variables
>>
>> Garrett Cooper and a few others have requested that I write a patch to fix a
>> regression w/respect to kenv(1) output in FreeBSD-9.0 and HEAD.
>>
>> The issue is with the new boot loader menu. It adds many loader variables
>> including ones that contain ANSI color escapes.
>>
>> Obviously, these ANSI codes don't play well with serial consoles when kenv(1)
> is
>> executed without arguments (reports vary as to what happens, but it's never
>> pretty).
>>
>> Attached is a patch to the Forth code that clears-out the menu-associated
>> variables before invoking the kernel.
>>
>> The net-effect is that kenv(1) no longer reports menu-related variables.
>>
>> In essence, kenv(1) output should now appear the same as on RELENG_8 (which
>> lacks the new boot loader and didn't use any such variables). Thus, restoring
>> serial console glory.
>> --
>> 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.

Great!

-- 
wbr,
pluknet
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: [PATCH] Fix kenv(1) output in w/respect to new boot loader variables

[Devin Teske]

D'Oh! Attached wrong (OLD; already applied) patch.

Please find appropriate patch attached!

> -Original Message-
> From: Devin Teske [mailto:devin.te...@fisglobal.com]
> Sent: Tuesday, December 27, 2011 5:24 PM
> To: 'freebsd-hackers@freebsd.org'
> Cc: Garrett Cooper; devin.te...@fisglobal.com
> Subject: [PATCH] Fix kenv(1) output in w/respect to new boot loader variables
> 
> Garrett Cooper and a few others have requested that I write a patch to fix a
> regression w/respect to kenv(1) output in FreeBSD-9.0 and HEAD.
> 
> The issue is with the new boot loader menu. It adds many loader variables
> including ones that contain ANSI color escapes.
> 
> Obviously, these ANSI codes don't play well with serial consoles when kenv(1)
is
> executed without arguments (reports vary as to what happens, but it's never
> pretty).
> 
> Attached is a patch to the Forth code that clears-out the menu-associated
> variables before invoking the kernel.
> 
> The net-effect is that kenv(1) no longer reports menu-related variables.
> 
> In essence, kenv(1) output should now appear the same as on RELENG_8 (which
> lacks the new boot loader and didn't use any such variables). Thus, restoring
> serial console glory.
> --
> 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.
--- src/sys/boot/forth/menu.4th.8.orig  Tue Dec 27 11:36:25 2011
+++ src/sys/boot/forth/menu.4th.8   Tue Dec 27 11:41:08 2011
@@ -24,7 +24,7 @@
 .\"
 .\" $FreeBSD: src/sys/boot/forth/menu.4th.8,v 1.2 2011/09/02 19:29:37 jh Exp $
 .\"
-.Dd Aug 29, 2011
+.Dd Dec 27, 2011
 .Dt MENU.4TH 8
 .Os
 .Sh NAME
@@ -69,9 +69,13 @@
 Calls
 .Ic menu-erase
 and then redraws the menu.
+.It Ic menu-unset
+Unsets the environment variables associated with individual menu items,
+clearing the way for a new menu.
 .It Ic menu-clear
-Unsets all possible environment variables used
-to configure the menu and then calls
+Calls
+.Ic menu-unset
+and then
 .Ic menu-erase .
 .El
 .Pp
--- src/sys/boot/forth/menu.4th.origFri Dec  2 11:17:45 2011
+++ src/sys/boot/forth/menu.4th Tue Dec 27 17:09:04 2011
@@ -131,11 +131,11 @@
 
\ Print the value of menuidx
loader_color? if
-   ." "
+   ." " (  )
then
menuidx @ .
loader_color? if
-   ." "
+   ." " (  )
then
 
\ Move the cursor forward 1 column
@@ -897,22 +897,60 @@
 ;
 
 \ This function unsets all the possible environment variables associated with
-\ creating the interactive menu. Call this when you want to clear the menu
-\ area in preparation for another menu.
+\ creating the interactive menu.
 \ 
-: menu-clear ( -- )
+: menu-unset ( -- )
 
49 \ Iterator start (loop range 49 to 56; ASCII '1' to '8')
begin
-   \ basename for caption variable
-   loader_color? if
-   s" ansi_caption[x]"
-   else
-   s" menu_caption[x]"
-   then
+   \ Unset variables in-order of appearance in menu.4th(8)
+
+   s" menu_caption[x]" \ basename for caption variable
-rot 2dup 13 + c! rot   \ replace 'x' with current iteration
unsetenv\ not erroneous to unset unknown var
 
+   s" menu_command[x]" \ command basename
+   -rot 2dup 13 + c! rot   \ replace 'x'
+   unsetenv
+
+   s" menu_keycode[x]" \ keycode basename
+   -rot 2dup 13 + c! rot   \ replace 'x'
+   unsetenv
+
+   s" ansi_caption[x]" \ ANSI caption basename
+   -rot 2dup 13 + c! rot   \ replace 'x'
+   unsetenv
+
+   s" toggled_text[x]" \ toggle_menuitem caption basename
+   -rot 2dup 13 + c! rot   \ replace 'x'
+   unsetenv
+
+   s" toggled_ansi[x]" \ toggle_menuitem ANSI caption basename
+   -rot 2dup 13 + c! rot   \ replace 'x'
+   unsetenv
+
+   s" menu_caption[x][y]"  \ cycle_menuitem caption
+   -rot 2dup 13 + c! rot   \ replace 'x'
+   49 -rot
+   begin
+   16 2over rot + c! \ rep

[PATCH] Fix kenv(1) output in w/respect to new boot loader variables

[Devin Teske]

Garrett Cooper and a few others have requested that I write a patch to fix a
regression w/respect to kenv(1) output in FreeBSD-9.0 and HEAD.

The issue is with the new boot loader menu. It adds many loader variables
including ones that contain ANSI color escapes.

Obviously, these ANSI codes don't play well with serial consoles when kenv(1) is
executed without arguments (reports vary as to what happens, but it's never
pretty).

Attached is a patch to the Forth code that clears-out the menu-associated
variables before invoking the kernel.

The net-effect is that kenv(1) no longer reports menu-related variables.

In essence, kenv(1) output should now appear the same as on RELENG_8 (which
lacks the new boot loader and didn't use any such variables). Thus, restoring
serial console glory.
-- 
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.
--- sys/boot/forth/menu.4th.origSat May 28 01:50:38 2011
+++ sys/boot/forth/menu.4th Wed Aug 24 23:46:46 2011
@@ -742,11 +742,10 @@
else
-rot 2drop
 
-   \ disable timeout if less than zero
+   \ boot immediately if less than zero
dup 0< if
drop
-   0 menu_timeout_enabled !
-   0 ( assigned to menu_timeout below )
+   0 boot
then
then
then
--- sys/boot/forth/menu.4th.8.orig  Sat May 28 01:50:38 2011
+++ sys/boot/forth/menu.4th.8   Wed Aug 24 23:45:57 2011
@@ -96,11 +96,15 @@
 by default) unless a key is pressed.
 If set to
 .Dq Li NO
-(case-insensitive) or
-.Dq Li -1 ,
+(case-insensitive)
 .Ic menu-display
 will wait for user input and never execute
 .Ic menu_timeout_command .
+If set to
+.Dq Li -1 ,
+.Ic menu-display
+will boot immediately, preventing both interruption of the autoboot process and
+escaping to the loader prompt.
 Default is
 .Dq Li 10 .
 See
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RELEASE] New Boot-Loader Menu bugs?

[John Baldwin]

On Monday, July 18, 2011 3:40:19 am Doug Barton wrote:
> On 07/17/2011 20:40, Devin Teske wrote:
> > What release are you running?
> 
> Recent HEAD

I upgraded my desktop at home to HEAD yesterday and tested this via a 'boot 
kernel.GENERIC' at the loader prompt and it did the same as the previous 
loader (module_path was /boot/kernel.GENERIC;/boot/kernel;/boot/modules), so I 
think the new boot loader menus work fine in this regard.

How exactly are you reproducing your broken case Doug?  Do you have any 
settings in /boot/loader.conf or /boot/loader.conf.local?

-- 
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RELEASE] New Boot-Loader Menu bugs?

[Doug Barton]

On 07/17/2011 20:40, Devin Teske wrote:
> What release are you running?

Recent HEAD


-- 

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RELEASE] New Boot-Loader Menu bugs?

[Devin Teske]

Hi Doug,

On Jul 17, 2011, at 5:08 PM, Doug Barton wrote:

> There also seems to be a bug with the new boot loader that if you bounce
> out to the prompt and do 'boot kernel.other' the kern.module_path sysctl
> is not updated. It still lists /boot/kernel first; but that should be
> replaced by /boot/kernel.other.

I had a chance to try this out in a VM.

I just tested this in FreeBSD 8.1-RELEASE with my loader_menu applied (exactly 
what's available from rev 222417).

The results I get are actually what you describe should happen.

Here's the steps I took:

1. Made sure all "kernel=" and "module_path=" lines were commented out in 
loader.conf(5)
2. Moved my kernel to /boot/kernel/kernel
3. Made a copy of my kernel to /boot/kernel2/kernel
4. Rebooted. Didn't touch anything. Verified that when I came up, `sysctl -n 
kern.bootfile' was /boot/kernel/kernel. Good. We have a baseline operation that 
things are working as-expected without interrupting the boot-process (that is 
to say, that loader(8) loaded the kernel in it's default location).
5. Reboot again. This time, I press Escape to the drop to the loader(8) prompt.
6. I took "boot /boot/kernel2"
7. I see the new kernel being loaded.
8. The kernel executes.
9. My system boots as-expected.
10. The value of sysctl kern.module_path produces (drum roll): 
/boot/kernel2;/boot/kernel;/boot/modules

What release are you running? I can't replicate the bug in 8.1-RELEASE with the 
new loader menu applied. It's possible that the bug was introduced some other 
way.
-- 
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.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RELEASE] New Boot-Loader Menu bugs?

[Devin Teske]

On Jul 17, 2011, at 5:08 PM, Doug Barton wrote:

> There also seems to be a bug with the new boot loader that if you bounce
> out to the prompt and do 'boot kernel.other'

Hmmm...

The last change to the FICL word "boot" was 10 years, 9 months ago, by dcs in 
version 1.19 of sys/boot/forth/loader.4th.

I know that I haven't touched that word, but I'll have to double-check to see 
if I'm overriding it in any way.

I can see by the code in loader.4th that "boot" will automatically call 
"unload" for you if/when an argument is present (e.g., "boot kernel.other").

I personally have never used that syntax (I've always said "unload" 
before-hand), but I will take it from the code that this is supposed to work.

> the kern.module_path sysctl
> is not updated.

If you want to change module_path for loader(8), you should set it in 
loader.conf(5). The FICL word "start" (as seen in /boot/loader.rc) will:

(a) read loader.conf(5) and then
(b) take your customized module_path and
(c) search for a suitable kernel in those directories
NOTE: that is, if "kernel" was not already set -- which it is, by default, to 
"/boot/kernel"

sysctl(8) is not (and, IIRC, cannot be) influenced by loader environment 
variables.

However, you can retrieve the loader(8) variables via kenv(1).

If you wanted to, you could create an rc.d or RCNG script to use kenv(1) to do 
things with the loader(8) variables (such as drop them into loader.conf(5) or 
sysctl.conf(5)). Be careful though.


> It still lists /boot/kernel first; but that should be
> replaced by /boot/kernel.other.

I'm not familiar with the latter behavior.
--
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.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FW: [RELEASE] New Boot-Loader Menu bugs?

[Doug Barton]

There also seems to be a bug with the new boot loader that if you bounce
out to the prompt and do 'boot kernel.other' the kern.module_path sysctl
is not updated. It still lists /boot/kernel first; but that should be
replaced by /boot/kernel.other.

-- 

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

FW: [RELEASE] New Boot-Loader Menu bugs?

[Teske, Devin]

-Original Message-
From: Devin Teske [mailto:dte...@vicor.com] 
Sent: Sunday, July 17, 2011 4:45 PM
To: 'Andrey Fesenko'; 'freebsd-hackers@freebsd.org'
Cc: Julian Elischer; Teske, Devin (devin.te...@fisglobal.com)
Subject: RE: [RELEASE] New Boot-Loader Menu bugs?

> -Original Message-
> From: Andrey Fesenko [mailto:f0and...@gmail.com]
> Sent: Sunday, July 17, 2011 12:33 AM
> To: freebsd-hackers@freebsd.org; dte...@vicor.com
> Subject: [RELEASE] New Boot-Loader Menu bugs?
> 
> Last Changed Rev: 224125

Are you sure that's the right rev? That rev (by dougb) appears to be related to 
default empty zones in `/etc/namedb/named.conf', and completely unrelated to my 
rev 222417 (which you appear to be referencing below).


> Not update share/examples/bootforth/* any files old version loader.
> 
> file sys/boot/forth/loader.conf
> ##
> ###  Loader settings  
> ##
> 
> not actual logo list
> #loader_logo="fbsdbw" # Desired logo: fbsdbw, beastiebw,
> beastie, none
> need
> #loader_logo="orbbw"  # Desired logo: orb, orbbw, fbsdbw, beastiebw,
> beastie, none
> 
> maybe over loader option.

It took me awhile, but I think I see what you're saying.

That the following patch needs to be applied to head/sys/boot/forth/loader.conf 
to be consistent with the changes that were made against 
head/sys/boot/forth/loader.conf.5 (in rev 222417):


--- loader.conf.origSun Jul 17 16:37:35 2011
+++ loader.conf Sun Jul 17 16:38:09 2011
@@ -47,7 +47,8 @@
# escape to the loader prompt, set to
# "NO" to disable autobooting
 #beastie_disable="NO"  # Turn the beastie boot menu on and off
-#loader_logo="fbsdbw"  # Desired logo: fbsdbw, beastiebw, beastie, none
+#loader_logo="orbbw"   # Desired logo: orb, orbbw, fbsdbw, beastiebw,
+   # beastie, none
 #comconsole_speed="9600"   # Set the current serial console speed
 #console="vidconsole"  # A comma separated list of console(s)
 #currdev="disk1s1a"# Set the current device


Does anybody object to the above patch?
-- 
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.
_
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

[RELEASE] New Boot-Loader Menu bugs?

[Andrey Fesenko]

Last Changed Rev: 224125

Not update share/examples/bootforth/* any files old version loader.

file sys/boot/forth/loader.conf
##
###  Loader settings  
##

not actual logo list
#loader_logo="fbsdbw"   # Desired logo: fbsdbw, beastiebw, beastie, none
need
#loader_logo="orbbw"# Desired logo: orb, orbbw, fbsdbw, beastiebw,
beastie, none

maybe over loader option.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RELEASE] New Boot-Loader Menu

[Devin Teske]

On May 29, 2011, at 6:08 PM, Julian Elischer wrote:

> On 5/29/11 2:53 PM, Devin Teske wrote:
>> On May 4, 2011, at 8:57 AM, Devin Teske wrote:
>> 
>>> On May 3, 2011, at 9:06 PM, Jason Hellenthal wrote:
>>> 
 Devin,
 
 
 On Sat, Apr 30, 2011 at 08:45:14PM -0700, Devin Teske wrote:
> On Apr 30, 2011, at 8:11 PM, Jason Hellenthal wrote:
> 
>> Devin,
>> 
>> 
>> On Sat, Apr 30, 2011 at 04:00:47PM -0700, Devin Teske wrote:
 Would be nice: "uname -v" of the kernel it will boot.
>>> That's a bit more technically challenging. I'll have another look at the
>>> FICL words available, but I don't recall if there was a way to crawl the
>>> object space of the items loaded with ``load'' (looking for the uname). 
>>> I'm
>>> open to suggestions if you had an idea of how to do this in Forth -- 
>>> else
>>> I'd think this would need to be a loader(8) modification.
>> How about forgetting a mention of unmae&  ... instead look into if we
>> can support some sort of bootcode versioning to be displayed on the
>> screen. This would serve to be very helpful in the future when for say a
>> new version of bootcode for ZFS has to be installed then it would be
>> easy for announce@ to simply say "A new version of ZFS has been MFCd and
>> requires boot version>= X. To find out your version please see the
>> bottom right hand corner of your boot screen."
>> 
>> I would place a pretty good bet that loader(8) could be modified to
>> export some sort of versioning of the bootcode to make this a easier
>> stance for the user to gather information before a upgrade.
> Piece of cake! If you give me a loader(8) that exports a "version" 
> environment variable, I'll give the Forth functionality in mere seconds. 
> It's already been developed (but was not packaged).
> 
> I have a module named "version.4th" which prints the value of the 
> "version" environment variable at the bottom-right of the screen 
> underneath the beastie logo.
> 
> Since you mention this, I'll add the code to the next package and if/when 
> loader(8) ever exports a "version" environment variable, it will just 
> magically appear. How's that sound?
> 
 Sounds perfect!
>>> One minor adjustment... can we make that environment variable 
>>> "loader_version" instead of "version"?
>>> 
>>> The code is already in for "loader_version". Whatever string you export 
>>> into that environment variable will be displayed on-screen at bottom-right, 
>>> right-justified.
>> The code for thew new menu has been committed to HEAD.
>> 
>> http://svnweb.freebsd.org/base?view=revision&revision=222417
>> 
>> Now...
>> 
>> Who wants to make the necessary patch to loader(8) to export $loader_version 
>> text?
>> 
>> Or maybe a suggestion on another list worth including on this?
> I suggest this move to -current since it is checked on there,
> and a port be kept for 8.x/7.x
> 
> Devin, a fix was made at 222450 as it was broken for ppc.
> 

Regarding fix 222450:

Oops. Slight oversight. Thanks for the one-liner fix.

Looks like we'll have to do the same thing for the following:

sys/boot/ia64/common/Makefile
sys/boot/powerpc/ps3/Makefile
sys/boot/sparc64/loader/Makefile

Here's a patch that can be applied by anyone willing:

http://druidbsd.sourceforge.net/download/loader_menu-1.6.1-HEAD20110521092952-fixup.patch

-- 
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.
_
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RELEASE] New Boot-Loader Menu

[Julian Elischer]

On 5/29/11 2:53 PM, Devin Teske wrote:

On May 4, 2011, at 8:57 AM, Devin Teske wrote:


On May 3, 2011, at 9:06 PM, Jason Hellenthal wrote:


Devin,


On Sat, Apr 30, 2011 at 08:45:14PM -0700, Devin Teske wrote:

On Apr 30, 2011, at 8:11 PM, Jason Hellenthal wrote:


Devin,


On Sat, Apr 30, 2011 at 04:00:47PM -0700, Devin Teske wrote:

Would be nice: "uname -v" of the kernel it will boot.

That's a bit more technically challenging. I'll have another look at the
FICL words available, but I don't recall if there was a way to crawl the
object space of the items loaded with ``load'' (looking for the uname). I'm
open to suggestions if you had an idea of how to do this in Forth -- else
I'd think this would need to be a loader(8) modification.

How about forgetting a mention of unmae&  ... instead look into if we
can support some sort of bootcode versioning to be displayed on the
screen. This would serve to be very helpful in the future when for say a
new version of bootcode for ZFS has to be installed then it would be
easy for announce@ to simply say "A new version of ZFS has been MFCd and
requires boot version>= X. To find out your version please see the
bottom right hand corner of your boot screen."

I would place a pretty good bet that loader(8) could be modified to
export some sort of versioning of the bootcode to make this a easier
stance for the user to gather information before a upgrade.

Piece of cake! If you give me a loader(8) that exports a "version" environment 
variable, I'll give the Forth functionality in mere seconds. It's already been developed 
(but was not packaged).

I have a module named "version.4th" which prints the value of the "version" 
environment variable at the bottom-right of the screen underneath the beastie logo.

Since you mention this, I'll add the code to the next package and if/when loader(8) ever 
exports a "version" environment variable, it will just magically appear. How's 
that sound?


Sounds perfect!

One minor adjustment... can we make that environment variable "loader_version" instead of 
"version"?

The code is already in for "loader_version". Whatever string you export into 
that environment variable will be displayed on-screen at bottom-right, right-justified.

The code for thew new menu has been committed to HEAD.

http://svnweb.freebsd.org/base?view=revision&revision=222417

Now...

Who wants to make the necessary patch to loader(8) to export $loader_version 
text?

Or maybe a suggestion on another list worth including on this?

I suggest this move to -current since it is checked on there,
and a port be kept for 8.x/7.x

Devin, a fix was made at 222450 as it was broken for ppc.



___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RELEASE] New Boot-Loader Menu

[Devin Teske]

On May 4, 2011, at 8:57 AM, Devin Teske wrote:

> 
> On May 3, 2011, at 9:06 PM, Jason Hellenthal wrote:
> 
>> 
>> Devin,
>> 
>> 
>> On Sat, Apr 30, 2011 at 08:45:14PM -0700, Devin Teske wrote:
>>> 
>>> On Apr 30, 2011, at 8:11 PM, Jason Hellenthal wrote:
>>> 
 
 Devin,
 
 
 On Sat, Apr 30, 2011 at 04:00:47PM -0700, Devin Teske wrote:
> 
>> Would be nice: "uname -v" of the kernel it will boot.
> 
> That's a bit more technically challenging. I'll have another look at the
> FICL words available, but I don't recall if there was a way to crawl the
> object space of the items loaded with ``load'' (looking for the uname). 
> I'm
> open to suggestions if you had an idea of how to do this in Forth -- else
> I'd think this would need to be a loader(8) modification.
 
 How about forgetting a mention of unmae & ... instead look into if we
 can support some sort of bootcode versioning to be displayed on the
 screen. This would serve to be very helpful in the future when for say a
 new version of bootcode for ZFS has to be installed then it would be
 easy for announce@ to simply say "A new version of ZFS has been MFCd and
 requires boot version >= X. To find out your version please see the
 bottom right hand corner of your boot screen."
 
 I would place a pretty good bet that loader(8) could be modified to
 export some sort of versioning of the bootcode to make this a easier
 stance for the user to gather information before a upgrade.
>>> 
>>> Piece of cake! If you give me a loader(8) that exports a "version" 
>>> environment variable, I'll give the Forth functionality in mere seconds. 
>>> It's already been developed (but was not packaged).
>>> 
>>> I have a module named "version.4th" which prints the value of the "version" 
>>> environment variable at the bottom-right of the screen underneath the 
>>> beastie logo.
>>> 
>>> Since you mention this, I'll add the code to the next package and if/when 
>>> loader(8) ever exports a "version" environment variable, it will just 
>>> magically appear. How's that sound?
>>> 
>> 
>> Sounds perfect!
> 
> One minor adjustment... can we make that environment variable 
> "loader_version" instead of "version"?
> 
> The code is already in for "loader_version". Whatever string you export into 
> that environment variable will be displayed on-screen at bottom-right, 
> right-justified.

The code for thew new menu has been committed to HEAD.

http://svnweb.freebsd.org/base?view=revision&revision=222417

Now...

Who wants to make the necessary patch to loader(8) to export $loader_version 
text?

Or maybe a suggestion on another list worth including on this?
-- 
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.
_
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

[RELEASE] New Boot-Loader Menu -- version 1.6

[Devin Teske]

Hi Hackers,

I'm pleased to announce version 1.6 of my new boot loader menu software.

NOTE: Version 1.6 has the same look and feel as version 1.5. No new screenshots 
needed.

This is a general cleanup with the below notable changes:

1. Change chkpassword.4th to query "password" environment variable instead of 
"loader_password" (for backward compatibility)
2. Rename chkpasswd function in chkpassword.4th to check-password (for backward 
compatibility)
3. Rename chkpassword.4th to check-password.4th (for consistency)
4. Replace conflicting check-password function in /boot/loader.4th with 
"include /boot/check-password.4th"
5. Remove conflicting password routines from /boot/support.4th
6. [Re-]Implement beastie-start in beastie.4th (for backward compatibility)
7. Replace loader.rc in the package with the default version provided on 
i386-compatible installs
8. Remove default delay in loading /boot/menu.rc (still available by setting 
loader_delay in loader.conf(5) but disabled by default now)
9. Add $FreeBSD$ CVS keywords in preparation of commit to HEAD
10. Fix a couple typos in comments
11. Add support for autoboot_delay="NO" or autoboot_delay="-1" in menu.4th to 
disable the menu timeout
12. Add missing cleanup routine to menu-clear in menu.4th
13. Add the following manpages:
/usr/share/man/man8/beastie.4th.8.gz
/usr/share/man/man8/brand.4th.8.gz
/usr/share/man/man8/check-password.4th.8.gz
/usr/share/man/man8/color.4th.8.gz
/usr/share/man/man8/delay.4th.8.gz
/usr/share/man/man8/menu.4th.8.gz
/usr/share/man/man8/version.4th.8.gz
14. Update loader.conf.5 manpage to include documentation on new loader_logo 
values (``orb'' and ``orbbw''), also documenting the new default (orbbw).

You can get your update from either:

http://druidbsd.sourceforge.net/
or
http://druidbsd.sourceforge.net/download/loader_menu-1.6.tgz
-- 
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.
_
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RELEASE] New Boot-Loader Menu -- version 1.5

[Tom Evans]

On Mon, May 16, 2011 at 1:50 PM, Andriy Gapon  wrote:
> on 16/05/2011 14:34 Tom Evans said the following:
>> I disagree entirely, the boot loader knows nothing of kernels
>
> Eh?  Maybe I misunderstand what you are saying, but:
>
> set kernel=kernel.old
> boot
>
> IMHO, it shows that you can tell the loader about kernels.
> Having a kernel-choice sub-menu would be convenient.
>

s/boot loader/boot manager/

My bad for the confusion.

The loader should definitely know about kernels; the boot manager,
which knows about BIOS bootable drives/partitions only, should not.

Cheers

Tom
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RELEASE] New Boot-Loader Menu -- version 1.5

[Andriy Gapon]

on 16/05/2011 14:34 Tom Evans said the following:
> I disagree entirely, the boot loader knows nothing of kernels

Eh?  Maybe I misunderstand what you are saying, but:

set kernel=kernel.old
boot

IMHO, it shows that you can tell the loader about kernels.
Having a kernel-choice sub-menu would be convenient.

-- 
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RELEASE] New Boot-Loader Menu -- version 1.5

[Tom Evans]

On Sat, May 14, 2011 at 9:36 PM, Mehmet Erol Sanliturk
 wrote:
> My main idea is that the present Boot-Loader Menu -- version 1.5 is a very
> good menu . Instead of destroying its elegant structure , the already
> available FreeBSD Boot Loader ( actually Kernel selection ) menu could be
> improved and may be used IF IT IS SUITABLE for the USER ( otherwise the user
> may not select it during installation ) .
>

I disagree entirely, the boot loader knows nothing of kernels, it only
presents the bootable drives/partitions as the BIOS sees it. Calling
the boot loader a kernel selection menu is disingenuous, since this is
simply a by-product of having different kernels on different
drives/partitions, whilst the most commonly desired kernel selection
(kernel vs kernel.old) is not available via this method.

Cheers

Tom
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RELEASE] New Boot-Loader Menu -- version 1.5

[Mehmet Erol Sanliturk]

On Sat, May 14, 2011 at 2:53 PM, Devin Teske  wrote:

> On May 14, 2011, at 8:14 AM, Mehmet Erol Sanliturk <
> m.e.sanlit...@gmail.com> wrote:
>
> On Sat, May 14, 2011 at 3:15 AM, Michael Reifenberger <
> m...@reifenberger.com> wrote:
>
>> Hi,
>> this looks very promising!
>>
>> While you are working on the loader front currently,
>> would it be possible to implement a "Boot kernel.old"
>> menue item that unloads all current loaded modules and re-loads
>> everithing from /boot/kernel.old?
>>
>> Its difficult to handle manually in the loader (esp. handling the
>> zpool.cache file ) and I got bitten by this issue recently in a ZFS only
>> environment.
>>
>> Thanks in advance!
>>
>> Bye/2
>> ---
>> Michael Reifenberger
>>  mich...@reifenberger.com
>>  http://www.Reifenberger.com
>>
>>
>
> There have been suggestions from many regarding "kernel selection" and even
> "root selection" options. I've responded in earnest on at least one such
> suggestion (stating that there are plans to incorporate these features at
> some later date), though I have been short on details (compared to my normal
> verbosity).
>
> These suggestions will have to be slated for a different commit and cannot
> make it into the initial one. A subset of the technical reasons are
> enumerated below:
>
> 1. Currently, the "start" FICL word provided by
> /usr/src/sys/boot/forth/loader.4th -- which reads in
> /boot/defaults/loader.conf and later /boot/loader.conf (if it exists), among
> other things -- pre-loads the configured kernel.
>
> This would need to change. We still want to call "start" from the onset of
> /boot/loader.rc to pick up any variables configured in loader.conf(5), but
> we don't want to load the kernel yet (though modules may be OK). I would
> change the overloaded "boot" word to load the kernel prior to calling the
> built-in boot ( N -- ) construct.
>
> 2. A non-trivial amount of Forth will need to be written to probe for a
> list of kernels to be presented.
>
> Again, that is just a subset of the technical affronts we'll face. I'd like
> to see this functionality pushed to a later SVN rev -- perhaps after MFC of
> the current rev planned for the current state.
>
>
> Many of the Unix/Linux operating systems are utilizing a Kernel Selection (
> let's call it Selection instead of Loader ) menu , such as GRUB or LILO , or
> ,
> in FreeBSD , when Kernel Selection menu is selected instead of booting
> directly from boot sector .
>
> Actually , a Kernel Selection menu in front of the Boot Loader menu is a
> more flexible method :
> First select kernel , then select its booting structure with the above
> described Boot Loader menu .
>
>
> My opinion is that , they should NOT be COMBINED into one single menu ,
> because , in the same system , even there may be other kernels to be booted
> .
>
>
> This would be technically simple to achieve but I'm wondering if the
> community would tolerate having a 2x 10-second timeout (one for kernel
> selection menu, and another for the boot/option menu). Then, if later a
> root-selection is provided, would that go into the kernel selection menu or
> a new menu (now requiring 30-seconds to boot without a human present).
>
> I want the menu with the "Boot" option to be front-and-center, continuing
> to allow the user to boot immediately with a single key ('1', 'b', or
> ENTER) if present (and desired), or if not present boot after a single
> 10-second timeout.
>
> ASIDE: There are more boot toggles/variables mentioned in loader(8) than
> are knobs in the boot menu (both old and new -- and more than can fit on a
> single screen even). Such as boot_ddb, boot_gdb, boot_multicons, boot_mute,
> boot_pause, boot_serial, and comconsole_speed. That's 7 additional options
> that would likely be a good candidate for a "side menu" (perhaps a "More
> Options" menuitem off the main menu).
>
> ASIDE: A root-selection menuitem could potentially present the normal root
> in addition to "ask", "cdrom" and "embedded". Each of which would set
> (respectively) "boot_askname", "boot_cdrom" and "boot_dfltroot". See
> loader(8) for additional details.
>
>
> Some operating systems , such as OpenSolaris and Mandriva Linux , after
> updating the kernel , they are keeping previous kernel in the Kernel
> Selection menu , under the new kernel name item .
>
>
> I've often felt that this could be improved upon by the Linux community.
> IMHO neither Grub nor LiLo present a user-friendly way of setting options
> for the selected kernel and concurrently leaves many Linux desktop-users
> befuddled and uninterested. The use-case is taking a box into single-user
> mode: FreeBSD achieves this with either one keystroke (current loader menu)
> or two (code being committed to HEAD; e.g., s, ENTER); compare that with
> the steps required to boot Linux into single-user mode from either LiLo or
> Grub (disclaimer: this might have been updated in some of the later Linux
> distros).
>
> NOTE: If you have a pre-

Re: [RELEASE] New Boot-Loader Menu -- version 1.5

[Devin Teske]

On May 14, 2011, at 8:14 AM, Mehmet Erol Sanliturk  
wrote:

> On Sat, May 14, 2011 at 3:15 AM, Michael Reifenberger  
> wrote:
> Hi,
> this looks very promising!
> 
> While you are working on the loader front currently,
> would it be possible to implement a "Boot kernel.old"
> menue item that unloads all current loaded modules and re-loads
> everithing from /boot/kernel.old?
> 
> Its difficult to handle manually in the loader (esp. handling the zpool.cache 
> file ) and I got bitten by this issue recently in a ZFS only environment.
> 
> Thanks in advance!
> 
> Bye/2
> ---
> Michael Reifenberger
> mich...@reifenberger.com
> http://www.Reifenberger.com
> 
> 

There have been suggestions from many regarding "kernel selection" and even 
"root selection" options. I've responded in earnest on at least one such 
suggestion (stating that there are plans to incorporate these features at some 
later date), though I have been short on details (compared to my normal 
verbosity).

These suggestions will have to be slated for a different commit and cannot make 
it into the initial one. A subset of the technical reasons are enumerated below:

1. Currently, the "start" FICL word provided by 
/usr/src/sys/boot/forth/loader.4th -- which reads in /boot/defaults/loader.conf 
and later /boot/loader.conf (if it exists), among other things -- pre-loads the 
configured kernel.

This would need to change. We still want to call "start" from the onset of 
/boot/loader.rc to pick up any variables configured in loader.conf(5), but we 
don't want to load the kernel yet (though modules may be OK). I would change 
the overloaded "boot" word to load the kernel prior to calling the built-in 
boot ( N -- ) construct.

2. A non-trivial amount of Forth will need to be written to probe for a list of 
kernels to be presented.

Again, that is just a subset of the technical affronts we'll face. I'd like to 
see this functionality pushed to a later SVN rev -- perhaps after MFC of the 
current rev planned for the current state.


> Many of the Unix/Linux operating systems are utilizing a Kernel Selection ( 
> let's call it Selection instead of Loader ) menu , such as GRUB or LILO , or ,
> in FreeBSD , when Kernel Selection menu is selected instead of booting 
> directly from boot sector .
> 
> Actually , a Kernel Selection menu in front of the Boot Loader menu is a more 
> flexible method :
> First select kernel , then select its booting structure with the above 
> described Boot Loader menu .
> 
> My opinion is that , they should NOT be COMBINED into one single menu , 
> because , in the same system , even there may be other kernels to be booted .

This would be technically simple to achieve but I'm wondering if the community 
would tolerate having a 2x 10-second timeout (one for kernel selection menu, 
and another for the boot/option menu). Then, if later a root-selection is 
provided, would that go into the kernel selection menu or a new menu (now 
requiring 30-seconds to boot without a human present).

I want the menu with the "Boot" option to be front-and-center, continuing to 
allow the user to boot immediately with a single key ('1', 'b', or ENTER) if 
present (and desired), or if not present boot after a single 10-second timeout.

ASIDE: There are more boot toggles/variables mentioned in loader(8) than are 
knobs in the boot menu (both old and new -- and more than can fit on a single 
screen even). Such as boot_ddb, boot_gdb, boot_multicons, boot_mute, 
boot_pause, boot_serial, and comconsole_speed. That's 7 additional options that 
would likely be a good candidate for a "side menu" (perhaps a "More Options" 
menuitem off the main menu).

ASIDE: A root-selection menuitem could potentially present the normal root in 
addition to "ask", "cdrom" and "embedded". Each of which would set 
(respectively) "boot_askname", "boot_cdrom" and "boot_dfltroot". See loader(8) 
for additional details.


> Some operating systems , such as OpenSolaris and Mandriva Linux , after 
> updating the kernel , they are keeping previous kernel in the Kernel 
> Selection menu , under the new kernel name item .

I've often felt that this could be improved upon by the Linux community. IMHO 
neither Grub nor LiLo present a user-friendly way of setting options for the 
selected kernel and concurrently leaves many Linux desktop-users befuddled and 
uninterested. The use-case is taking a box into single-user mode: FreeBSD 
achieves this with either one keystroke (current loader menu) or two (code 
being committed to HEAD; e.g., s, ENTER); compare that with the steps required 
to boot Linux into single-user mode from either LiLo or Grub (disclaimer: this 
might have been updated in some of the later Linux distros).

NOTE: If you have a pre-configured Grub or LiLo entry for easily entering into 
single-user mode, note that not everybody is so fortunate (either because of 
their distro or due to lack of manual configuration). Even still, a variable 
amount of cursor/arrow keys

Re: [RELEASE] New Boot-Loader Menu -- version 1.5

[Mehmet Erol Sanliturk]

On Sat, May 14, 2011 at 3:15 AM, Michael Reifenberger  wrote:

> Hi,
> this looks very promising!
>
> While you are working on the loader front currently,
> would it be possible to implement a "Boot kernel.old"
> menue item that unloads all current loaded modules and re-loads
> everithing from /boot/kernel.old?
>
> Its difficult to handle manually in the loader (esp. handling the
> zpool.cache file ) and I got bitten by this issue recently in a ZFS only
> environment.
>
> Thanks in advance!
>
> Bye/2
> ---
> Michael Reifenberger
> mich...@reifenberger.com
> http://www.Reifenberger.com
>
>
Many of the Unix/Linux operating systems are utilizing a Kernel Selection (
let's call it Selection instead of Loader ) menu , such as GRUB or LILO , or
,
in FreeBSD , when Kernel Selection menu is selected instead of booting
directly from boot sector .

Actually , a Kernel Selection menu in front of the Boot Loader menu is a
more flexible method :
First select kernel , then select its booting structure with the above
described Boot Loader menu .

My opinion is that , they should NOT be COMBINED into one single menu ,
because , in the same system , even there may be other kernels to be booted
.

Some operating systems , such as OpenSolaris and Mandriva Linux , after
updating the kernel , they are keeping previous kernel in the Kernel
Selection menu , under the new kernel name item .

Such a system may be employed for the FreeBSD : If a kernel.old is generated
, it may be inserted into Kernel Selection menu automatically . If , at
present , there is no kernel selection menu but boot sector is used directly
, kernel build system may modify that structure also to utilize a Kernel
Selection menu .


Thank you very much .


Mehmet Erol Sanliturk
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RELEASE] New Boot-Loader Menu -- version 1.5

[Michael Reifenberger]

Hi,
this looks very promising!

While you are working on the loader front currently,
would it be possible to implement a "Boot kernel.old"
menue item that unloads all current loaded modules and re-loads
everithing from /boot/kernel.old?

Its difficult to handle manually in the loader (esp. handling the zpool.cache 
file ) and I got bitten by this issue recently in a ZFS only environment.


Thanks in advance!

Bye/2
---
Michael Reifenberger
mich...@reifenberger.com
http://www.Reifenberger.com

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: [RELEASE] New Boot-Loader Menu -- version 1.5

[Devin Teske]

> -Original Message-
> From: Devin Teske [mailto:dte...@vicor.com]
> Sent: Friday, May 13, 2011 6:22 PM
> To: freebsd-hackers@freebsd.org
> Cc: '兰清'; 'Alexander Leidinger'; 'Dieter BSD'; Teske, Devin
> (devin.te...@fisglobal.com); Julian Elischer (jelisc...@fusionio.com); 'Warner
> Losh'
> Subject: [RELEASE] New Boot-Loader Menu -- version 1.5
> 
> Happy to bring to you version 1.5 of my loader_menu package. This version
> incorporates the suggestions first made by Lan Qing and then re-affirmed by
(in-
> order) Alexander Leidinger, Dieter BSD, and Julian Elischer (whom brings word
> from the devsummit as well as Warner Losh): you guys want to separate the boot
> "actions" from the boot "options", and now it's accomplished.
> 
> Here's how the re-arrangement looks for each of the different loader
> environments...

i386-compatible hardware with ACPI support:
http://twitpic.com/4wvls8
http://twitpic.com/4wvm73 (color)

i386-compatible hardware without ACPI support:
http://twitpic.com/4wvmod
http://twitpic.com/4wvn0f

non-i386 (such as IA64, PPC, etc.):
http://twitpic.com/4wvne3
http://twitpic.com/4wvod5 (color)

NOTE: Previous links were incorrect. Above are the correct links to the correct
images.
-- 
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.
_
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

[RELEASE] New Boot-Loader Menu -- version 1.5

[Devin Teske]

Happy to bring to you version 1.5 of my loader_menu package. This version
incorporates the suggestions first made by Lan Qing and then re-affirmed by
(in-order) Alexander Leidinger, Dieter BSD, and Julian Elischer (whom brings
word from the devsummit as well as Warner Losh): you guys want to separate the
boot "actions" from the boot "options", and now it's accomplished.

Here's how the re-arrangement looks for each of the different loader
environments...

i386-compatible hardware with ACPI support:
http://twitpic.com/4wvls8
http://twitpic.com/4wvn0f (color)

i386-compatible hardware without ACPI support:
http://twitpic.com/4wvmod
http://twitpic.com/4wvn0f (color)

non-i386 hardware (such as IA64, PPC, etc.):
http://twitpic.com/4wvne3
http://twitpic.com/4wvod5 (color)

Here's the links:

http://druidbsd.sourceforge.net/download/loader_menu-1.5.tgz
or
http://druidbsd.sourceforge.net/

Here's a diff of the changes:

diff -rNup loader_menu-1.4/+CONTENTS loader_menu-1.5/+CONTENTS
--- loader_menu-1.4/+CONTENTS   2011-05-05 00:47:31.0 -0700
+++ loader_menu-1.5/+CONTENTS   2011-05-12 16:07:11.0 -0700
@@ -1,5 +1,5 @@
 @comment PKG_FORMAT_REVISION:1.1
-@name loader_menu-1.4
+@name loader_menu-1.5
 @comment ORIGIN:sysutils/loader_menu
 @cwd /boot
 beastie.4th
@@ -17,9 +17,9 @@ loader.rc
 menu-commands.4th
 @comment MD5:0999bd50b8395098bd6bcf9165db4d7b
 menu.4th
-@comment MD5:26a61c0ea268334687a63e07b0d708d8
+@comment MD5:3b97638b4a5608fab425e2751d386c14
 menu.rc
-@comment MD5:dcf2993118b991f57b4ab0659d2712ae
+@comment MD5:f682160708bcf5a537421ab09ce51660
 shortcuts.4th
 @comment MD5:9a5ed52548bbbaf67ad613e37d0e4b58
 version.4th
@@ -30,7 +30,7 @@ version.4th
 @comment MD5:69903862d8df34df77522792172b0999
 @ignore
 +DESC
-@comment MD5:d18419e5babe54b7cc195da7f7f5ac86
+@comment MD5:597ef7a6779d9e083140eaa985fc1ee1
 @ignore
 +INSTALL
 @comment MD5:76c98eb5e084871d9fe5d4fa4511d8c5
diff -rNup loader_menu-1.4/+DESC loader_menu-1.5/+DESC
--- loader_menu-1.4/+DESC   2011-05-04 12:11:31.0 -0700
+++ loader_menu-1.5/+DESC   2011-05-12 13:50:40.0 -0700
@@ -91,6 +91,11 @@ loader_delay="N"
until booting the loaded kernel). During the autoboot sequence, any key
pressed except for ENTER will allow escaping to the loader prompt.
 
+loader_menu_title="..."
+
+   Overrides the default title ("Welcome to FreeBSD") displayed above the
+   dynamic menu.
+
 
 
 WWW: http://druidbsd.sourceforge.net/
diff -rNup loader_menu-1.4/menu.4th loader_menu-1.5/menu.4th
--- loader_menu-1.4/menu.4th2011-05-05 00:33:13.0 -0700
+++ loader_menu-1.5/menu.4th2011-05-12 16:07:06.0 -0700
@@ -75,7 +75,9 @@ variable menukey6
 variable menukey7
 variable menukey8
 variable menureboot
+variable menurebootadded
 variable menuacpi
+variable menuoptions
 
 \ Menu timer [count-down] variables
 variable menu_timeout_enabled \ timeout state (internal use only)
@@ -439,7 +441,10 @@ create init_text8 255 allot
 : menu-create ( -- )
 
\ Print the frame caption at (x,y)
-   11 9 at-xy ." FreeBSD Kernel Options"
+   s" loader_menu_title" getenv dup -1 = if
+   drop s" Welcome to FreeBSD"
+   then
+   24 over 2 / - 9 at-xy type 
 
\ Print our menu options with respective key/variable associations.
\ `printmenuitem' ends by adding the decimal ASCII value for the
@@ -478,8 +483,39 @@ create init_text8 255 allot
then
then
 
+   \ 
+   \ Initialize the menu_options visual separator.
+   \ 
+   0 menuoptions !
+   s" menu_options" getenv -1 <> if
+   c@ dup 48 > over 57 < and if ( '1' <= c1 <= '8' )
+   menuoptions !
+   else
+   drop
+   then
+   then
+
+   \ Initialize "Reboot" menu state variable (prevents double-entry)
+   false menurebootadded !
+
49 \ Iterator start (loop range 49 to 56; ASCII '1' to '8')
begin
+   \ If the "Options:" separator, print it.
+   dup menuoptions @ = if
+   \ Optionally add a reboot option to the menu
+   s" menu_reboot" getenv -1 <> if
+   drop
+   s" Reboot" printmenuitem menureboot !
+   true menurebootadded !
+   then
+
+   menuX @
+   menurow @ 2 + menurow !
+   menurow @ menuY @ +
+   at-xy
+   ." Options:"
+   then
+
\ If this is the ACPI menu option, act accordingly.
dup menuacpi @ = if
acpimenuitem ( -- C-Addr | -1 )
@@ -520,14 +556,16 @@ create init_text8 255 allot
drop \ iterator
 
\ Optionally add a reboot option to the menu
-   s" menu_reboot" getenv -1 <> if
-   drop   \ no need for th

Re: [UPDATE] New Boot-Loader Menu -- version 1.3

[Julian Elischer]

On 5/12/11 2:14 PM, Devin Teske wrote:

On May 4, 2011, at 1:37 AM, Emanuel Haupt wrote:


Devin Teske  wrote:

Hey all,

Proud to bring you version 1.3 which completes the followup
suggestions made by Olivier Smedts (use autoboot_delay instead of
loader_menu_timeout and change dc_seconds to loader_delay) and a
couple other minor enhancements/fixes.

I think that brings everything up to speed with the phenomenal
feedback provided so far. Really, thank you all very much.

Get your update at http://druidbsd.sf.net/ or
http://druidbsd.sourceforge.net/download/loader_menu-1.3.tgz

Devin, have you thought about writing a port [1]? I'd be happy to
review it:

port would be good for 8
it'll be in 9 by default (we just decided a the devsummit) (if there 
are no roadblocks)



[1]

http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/own-port.html
I'm going to see if I can't make it perfectly acceptable for base first. If the
final version gets rejected for submission to base, I'll turn to ports.

On a side-note, it'd be a pretty interesting port... considering the fact that
I'm already distributing it as a FreeBSD package (what would the Makefile for
that port look like... a call to fetch followed by a call to pkg_add ?? lol --
are there other ports that already work like that?).



Confidentiality Notice: This e-mail message, its contents and any attachments 
to it are confidential to the intended recipient, and may contain information 
that is privileged and/or exempt from disclosure under applicable law. If you 
are not the intended recipient, please immediately notify the sender and 
destroy the original e-mail message and any attachments (and any copies that 
may have been made) from your system or otherwise. Any unauthorized use, 
copying, disclosure or distribution of this information is strictly prohibited.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [UPDATE] New Boot-Loader Menu -- version 1.3

[Warner Losh]

On May 12, 2011, at 2:14 PM, Devin Teske wrote:

>> On May 4, 2011, at 1:37 AM, Emanuel Haupt wrote:
>> 
>>> Devin Teske  wrote:
>>> 
>>> Hey all,
>>> 
>>> Proud to bring you version 1.3 which completes the followup
>>> suggestions made by Olivier Smedts (use autoboot_delay instead of
>>> loader_menu_timeout and change dc_seconds to loader_delay) and a
>>> couple other minor enhancements/fixes.
>>> 
>>> I think that brings everything up to speed with the phenomenal
>>> feedback provided so far. Really, thank you all very much.
>>> 
>>> Get your update at http://druidbsd.sf.net/ or
>>> http://druidbsd.sourceforge.net/download/loader_menu-1.3.tgz
>> 
>> Devin, have you thought about writing a port [1]? I'd be happy to
>> review it:
>> 
>> [1]
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/own-port.html
>> 
> 
> I'm going to see if I can't make it perfectly acceptable for base first. If 
> the
> final version gets rejected for submission to base, I'll turn to ports.
> 
> On a side-note, it'd be a pretty interesting port... considering the fact that
> I'm already distributing it as a FreeBSD package (what would the Makefile for
> that port look like... a call to fetch followed by a call to pkg_add ?? lol --
> are there other ports that already work like that?).

In the FreeBSD developer's summit today, there was broad support for bringing 
it into base for 9.0.

Warner

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: [UPDATE] New Boot-Loader Menu -- version 1.3

[Devin Teske]

> On May 4, 2011, at 1:37 AM, Emanuel Haupt wrote:
> 
>> Devin Teske  wrote:
>> 
>> Hey all,
>> 
>> Proud to bring you version 1.3 which completes the followup
>> suggestions made by Olivier Smedts (use autoboot_delay instead of
>> loader_menu_timeout and change dc_seconds to loader_delay) and a
>> couple other minor enhancements/fixes.
>> 
>> I think that brings everything up to speed with the phenomenal
>> feedback provided so far. Really, thank you all very much.
>> 
>> Get your update at http://druidbsd.sf.net/ or
>> http://druidbsd.sourceforge.net/download/loader_menu-1.3.tgz
> 
> Devin, have you thought about writing a port [1]? I'd be happy to
> review it:
> 
> [1]
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/own-port.html
> 

I'm going to see if I can't make it perfectly acceptable for base first. If the
final version gets rejected for submission to base, I'll turn to ports.

On a side-note, it'd be a pretty interesting port... considering the fact that
I'm already distributing it as a FreeBSD package (what would the Makefile for
that port look like... a call to fetch followed by a call to pkg_add ?? lol --
are there other ports that already work like that?).
-- 
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.
_
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [UPDATE] New Boot-Loader Menu -- version 1.4

[Lars Engels]

Kris Moore CC'ed


On Mon, May 09, 2011 at 10:41:40AM -0700, Devin Teske wrote:
> > -Original Message-
> > From: Lars Engels [mailto:lars.eng...@0x20.net]
> > Sent: Monday, May 09, 2011 2:19 AM
> > To: Devin Teske
> > Cc: FreeBSD Hackers
> > Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.4
> > 
> > On Thu, May 05, 2011 at 01:20:43AM -0700, Devin Teske wrote:
> > > Hello fellow -hackers,
> > >
> > > I'm so very proud to offer the latest update to my new boot loader
> > > menu -- version 1.4 -- addressing ACPI detection, bringing it in-line
> > > with HEAD.
> > >
> > > It took some work and a few days, but I got it! Have a look below for
> > > six different displays (three different scenarios -- i386 w/ ACPI,
> > > i386 w/o ACPI, and non-i386 -- each in both B&W and Color).
> > >
> > 
> > Hi Devin,
> > 
> > PC-BSD also has a slightly patched loader menu compared to the stock FreeBSD
> > version.
> 
> Does PC-BSD have CVSweb that I can browse? Link?

http://trac.pcbsd.org/browser/pcbsd/current/system-overlay/boot

> 
> > I.E. you can also set unset verbose mode and ACPI with it.
> > Some days ago there was a proposal on a PC-BSD list to add an option to 
> > boot a
> > different kernel if one is found in /boot.
> > Would it be possible to addi this function to your boot menu?
> 
> No need. The basic constructs are there already, we just need to expand on 
> them.
> 
> Here's how I've implemented a hard-coded list of kernels to choose from for 
> our systems (to be implemented in /boot/menu.rc):
> 
> \ Set kernel paths (see menu_caption[2] below)
> set kernel_prefix="/kernels/"
>   \ NOTE: We like to keep our kernels in `/kernels'
> set kernel[0]="FIS-i386-8.1p1"
> set kernel[1]="GENERIC-i386-8.1p1"
> set kernel_suffix=".kgz"
>   \ NOTE: This is on our CD/DVD, so kernels are kgzip(8)'d
> 
> \ Set default boot kernel
> set kernel="${kernel_prefix}${kernel[0]}${kernel_suffix}"
> 
> \ Initialize main menu constructs (variables are read by `menu.4th')
> 
> set menu_caption[1]="Boot [ENTER]"
> set menu_command[1]="boot"
> 
> set menu_caption[2][0]="Kernel: ${kernel[0]} (1of2)"
> set menu_caption[2][1]="Kernel: ${kernel[1]} (2of2)"
> set menu_caption[2]="${menu_caption[2][0]}"
> set menu_command[2]="cycle_kernel"
> 
> \ ... rest of menu ...
> 
> The magic is the "cycle_kernel" command (see `/boot/menu.4th'). The 
> `cycle_kernel' command is a wrapper to the `cycle_menuitem' command (similar 
> to how `toggle_verbose', `toggle_acpi', and `toggle_singleuser' are wrappers 
> to the `toggle_menuitem' command). Like the `toggle_menuitem' command, the 
> `cycle_menuitem' command uses a system of internal state variables to track 
> which menuitem text is to be displayed for that individual menuitem. Whereas 
> the `toggle_menuitem' command automatically toggles the text of a menuitem 
> between the `menu_caption[x]' and `toggled_text[x]' variables, the 
> `cycle_menuitem' command automatically cycles through the 
> `menu_caption[x][y]' variables, cycling back to y=0 when it gets to an 
> undefined `y' value.
> 
> However, hard-coding an alternate kernel choice is something that I wouldn't 
> condone for an actual release. Instead, what I would recommend is to 
> dynamically allocate the kernel menu if/when multiple kernels are 
> discovered/configured. That's something that is currently not coded (dynamic 
> detection of kernels in /boot).
> 
> > Or even better
> > work together with Kris Moore so we don't have two solutions for the same 
> > task?
> 
> I'd like to open a discussion with Kris Moore on how we could go about 
> detecting additional kernels.
> 
> Off the top of my head, here's a couple thoughts:
> 
> a. We could test a battery of different kernel names (kernel, kernel.bak, 
> kernel.orig, etc.)
> b. We could allow the user to set kernel1, kernel2, kernel3, etc. in 
> loader.conf(5)
> c. We could allow the user to set kernel="kernel1;kernel2;kernel3;..." in 
> loader.conf(5)
> d. Some combination of the above.
> -- 
> Devin
> 
> P.S. I think it'd also be nice to someday offer the user a choice of booting 
> into a memory filesystem for rescue purposes. We've offered this to our users 
> for years with the following configuration:
> 
> set root[0]=""
> set root[1]="rescue_mfsroot"
> set menu_caption[7][0]="Root Image: Default (1of2)"
> set menu_caption[7][1]="Root Image: Rescue (2of2)"
> set menu_caption[7]="${menu_caption[7][0]}"
> set menu_command[7]="cycle_root"
> 

Good idea! :-)


pgpRnhpUhwmGX.pgp
Description: PGP signature

Re: [UPDATE] New Boot-Loader Menu -- version 1.4

[Warren Block]

On Mon, 9 May 2011, Alexander Leidinger wrote:


IMO it's either
- change now
or
- no change, never ever
or
- change if special variable is set


In case it hasn't already been suggested...

Just make the loader read a template file that defines the menu.  The 
port or base system can include a standard menu file, and everyone else 
can set it up however they want.  As an example, see syslinux or grub or 
any number of similar boot menus.

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [UPDATE] New Boot-Loader Menu -- version 1.4

[Alexander Leidinger]

On Sun, 8 May 2011 13:45:55 -0700 Devin Teske  wrote:

> On May 8, 2011, at 12:13 PM, Alexander Leidinger wrote:
> 
> > On Sun, 8 May 2011 10:48:55 -0700 Devin Teske 
> > wrote:
> > 
> >> I would like to see general consensus from the community for
> >> separating the items before moving ahead with such a non-trivial
> >> change.
> > 
> > IMO:
> > - I agree that there are two different types of actions
> > - having 2 distinct blocks looks like a good idea to me
> >   (I didn't had a look at the code, if you only have the text
> >in the variables and the numbers get added automatically,
> >maybe you can add variables for inbetween items which
> >are pure text and do not get a number, and they are not
> >displayed if the variable is empty)
> > - I do not think that we need two different namespaces here
> >   -> reorder the items, use incrementing numbers no matter
> >  which type it is (ACPI would be number 4 in the example then)
> 
> 
> All-in-all, I love the suggestion.
> 
> A few notes:
> - I also agree that there are two different types of actions
> - Significant changes would need to be made.
> - I'd like to take the gradual approach
> - You're right, it could be done without two different namespaces
> 
> However, there's one very important fact...
> 
> The current menu is "numbers only" which means that people that use
> the menu often will be impacted in a non-trivial way if we re-order
> the numbers.
> 
> The gradual approach would have us accept a new menu (such as
> loader_menu-1.4) that enables the use of hotkeys. Get people used to
> using the hotkeys for awhile before re-ording (or perhaps even
> taking-away) the numbers.
> 
> What do you think of the gradual approach?

If you want to spend some years...

IMO it's either
 - change now
or
 - no change, never ever
or
 - change if special variable is set

I do not think it is really an option to change it only for new
installs but keep the numbers for installed ones as they are (if there
is a way to do this).

I also think that there will always be some people which never switch
to hotkeys.

FYI: I never got the numbers into my brain, I always use SPACE to pause
and then read which number to press. This could be because I do not
(re)boot systems much, but I expect/hope that there are more people
which do the same. With the hotkeys this may change, as they are easy
to associate with the English word for the action.

I'm all for gradual improvements, but there are things which can not be
done gradually. This usability improvement is one of the later ones
IMO. If nobody complains that such a separation is very hard to get and
that it is too hard to press SPACE and that the ordering of the new
entries can only be provided by someone with a twisted brain, I would
do it, as it looks like very good and better understandable usability
improvement which should get new users (to FreeBSD but maybe not to
the Unix way) to better get suited with FreeBSD. Maybe an explicit
variable to set to go back to the old order if there are too much
voices which tell it would violate POLA?

Bye,
Alexander.

-- 
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: [UPDATE] New Boot-Loader Menu -- version 1.4

[Devin Teske]

> -Original Message-
> From: Lars Engels [mailto:lars.eng...@0x20.net]
> Sent: Monday, May 09, 2011 2:19 AM
> To: Devin Teske
> Cc: FreeBSD Hackers
> Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.4
> 
> On Thu, May 05, 2011 at 01:20:43AM -0700, Devin Teske wrote:
> > Hello fellow -hackers,
> >
> > I'm so very proud to offer the latest update to my new boot loader
> > menu -- version 1.4 -- addressing ACPI detection, bringing it in-line
> > with HEAD.
> >
> > It took some work and a few days, but I got it! Have a look below for
> > six different displays (three different scenarios -- i386 w/ ACPI,
> > i386 w/o ACPI, and non-i386 -- each in both B&W and Color).
> >
> 
> Hi Devin,
> 
> PC-BSD also has a slightly patched loader menu compared to the stock FreeBSD
> version.

Does PC-BSD have CVSweb that I can browse? Link?


> I.E. you can also set unset verbose mode and ACPI with it.
> Some days ago there was a proposal on a PC-BSD list to add an option to boot a
> different kernel if one is found in /boot.
> Would it be possible to addi this function to your boot menu?

No need. The basic constructs are there already, we just need to expand on them.

Here's how I've implemented a hard-coded list of kernels to choose from for our 
systems (to be implemented in /boot/menu.rc):

\ Set kernel paths (see menu_caption[2] below)
set kernel_prefix="/kernels/"
\ NOTE: We like to keep our kernels in `/kernels'
set kernel[0]="FIS-i386-8.1p1"
set kernel[1]="GENERIC-i386-8.1p1"
set kernel_suffix=".kgz"
\ NOTE: This is on our CD/DVD, so kernels are kgzip(8)'d

\ Set default boot kernel
set kernel="${kernel_prefix}${kernel[0]}${kernel_suffix}"

\ Initialize main menu constructs (variables are read by `menu.4th')

set menu_caption[1]="Boot [ENTER]"
set menu_command[1]="boot"

set menu_caption[2][0]="Kernel: ${kernel[0]} (1of2)"
set menu_caption[2][1]="Kernel: ${kernel[1]} (2of2)"
set menu_caption[2]="${menu_caption[2][0]}"
set menu_command[2]="cycle_kernel"

\ ... rest of menu ...

The magic is the "cycle_kernel" command (see `/boot/menu.4th'). The 
`cycle_kernel' command is a wrapper to the `cycle_menuitem' command (similar to 
how `toggle_verbose', `toggle_acpi', and `toggle_singleuser' are wrappers to 
the `toggle_menuitem' command). Like the `toggle_menuitem' command, the 
`cycle_menuitem' command uses a system of internal state variables to track 
which menuitem text is to be displayed for that individual menuitem. Whereas 
the `toggle_menuitem' command automatically toggles the text of a menuitem 
between the `menu_caption[x]' and `toggled_text[x]' variables, the 
`cycle_menuitem' command automatically cycles through the `menu_caption[x][y]' 
variables, cycling back to y=0 when it gets to an undefined `y' value.

However, hard-coding an alternate kernel choice is something that I wouldn't 
condone for an actual release. Instead, what I would recommend is to 
dynamically allocate the kernel menu if/when multiple kernels are 
discovered/configured. That's something that is currently not coded (dynamic 
detection of kernels in /boot).

> Or even better
> work together with Kris Moore so we don't have two solutions for the same 
> task?

I'd like to open a discussion with Kris Moore on how we could go about 
detecting additional kernels.

Off the top of my head, here's a couple thoughts:

a. We could test a battery of different kernel names (kernel, kernel.bak, 
kernel.orig, etc.)
b. We could allow the user to set kernel1, kernel2, kernel3, etc. in 
loader.conf(5)
c. We could allow the user to set kernel="kernel1;kernel2;kernel3;..." in 
loader.conf(5)
d. Some combination of the above.
-- 
Devin

P.S. I think it'd also be nice to someday offer the user a choice of booting 
into a memory filesystem for rescue purposes. We've offered this to our users 
for years with the following configuration:

set root[0]=""
set root[1]="rescue_mfsroot"
set menu_caption[7][0]="Root Image: Default (1of2)"
set menu_caption[7][1]="Root Image: Rescue (2of2)"
set menu_caption[7]="${menu_caption[7][0]}"
set menu_command[7]="cycle_root"



_

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.
_
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [UPDATE] New Boot-Loader Menu -- version 1.4

[Lars Engels]

On Thu, May 05, 2011 at 01:20:43AM -0700, Devin Teske wrote:
> Hello fellow -hackers,
> 
> I'm so very proud to offer the latest update to my new boot loader
> menu -- version 1.4 -- addressing ACPI detection, bringing it in-line
> with HEAD.
> 
> It took some work and a few days, but I got it! Have a look below for
> six different displays (three different scenarios -- i386 w/ ACPI,
> i386 w/o ACPI, and non-i386 -- each in both B&W and Color).
> 

Hi Devin,

PC-BSD also has a slightly patched loader menu compared to the stock
FreeBSD version. I.E. you can also set unset verbose mode and ACPI with
it.
Some days ago there was a proposal on a PC-BSD list to add an option to
boot a different kernel if one is found in /boot.
Would it be possible to addi this function to your boot menu? Or even
better work together with Kris Moore so we don't have two solutions for
the same task?

Lars


pgpTDrYVktqJU.pgp
Description: PGP signature

Re: [RELEASE] New Boot-Loader Menu

[Dieter BSD]

> There's really only room for one or two more menu items.

Perhaps some items could be moved to a 2nd level menu?

1) boot multiuser mode ( default )
2) boot single user mode
3) menu to set boot options
4) help

 Would be nice: a fix for having to lean on a key autorepeating
 for a couple seconds.
>>>
>>> Could you explain? I don't follow.
>>
>> On my Tyan Tomcat k8e 2865, just entering the number rarely if
>> ever works. I have to either repeatedly bang away at the key or
>> hold it down, letting the RS-232 terminal do the autorepeat thing,
>> while hoping that it notices before the timer runs out.
>
> Is that with the current code that's in CVS? I'd love for you to
> try my code on that hardware. One of the things that I worked on
> in the very beginning was the responsiveness.

That's with 6.x, 7,x and 8.x, currently running 8.2.  I haven't
looked to see if anything has changed in CVS since 8.2.  I'll
try your code, but I can't promise when.  I'm swamped at the
moment and windows when the machine is free keep getting smaller
and less frequent.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [UPDATE] New Boot-Loader Menu -- version 1.4

[Alexander Leidinger]

On Sun, 8 May 2011 10:48:55 -0700 Devin Teske  wrote:

> I would like to see general consensus from the community for
> separating the items before moving ahead with such a non-trivial
> change.

IMO:
 - I agree that there are two different types of actions
 - having 2 distinct blocks looks like a good idea to me
   (I didn't had a look at the code, if you only have the text
in the variables and the numbers get added automatically,
maybe you can add variables for inbetween items which
are pure text and do not get a number, and they are not
displayed if the variable is empty)
 - I do not think that we need two different namespaces here
   -> reorder the items, use incrementing numbers no matter
  which type it is (ACPI would be number 4 in the example then)

Bye,
Alexander.

-- 
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [UPDATE] New Boot-Loader Menu -- version 1.4

[Devin Teske]

On May 8, 2011, at 12:13 PM, Alexander Leidinger wrote:

> On Sun, 8 May 2011 10:48:55 -0700 Devin Teske  wrote:
> 
>> I would like to see general consensus from the community for
>> separating the items before moving ahead with such a non-trivial
>> change.
> 
> IMO:
> - I agree that there are two different types of actions
> - having 2 distinct blocks looks like a good idea to me
>   (I didn't had a look at the code, if you only have the text
>in the variables and the numbers get added automatically,
>maybe you can add variables for inbetween items which
>are pure text and do not get a number, and they are not
>displayed if the variable is empty)
> - I do not think that we need two different namespaces here
>   -> reorder the items, use incrementing numbers no matter
>  which type it is (ACPI would be number 4 in the example then)


All-in-all, I love the suggestion.

A few notes:
- I also agree that there are two different types of actions
- Significant changes would need to be made.
- I'd like to take the gradual approach
- You're right, it could be done without two different namespaces

However, there's one very important fact...

The current menu is "numbers only" which means that people that use the menu 
often will be impacted in a non-trivial way if we re-order the numbers.

The gradual approach would have us accept a new menu (such as loader_menu-1.4) 
that enables the use of hotkeys. Get people used to using the hotkeys for 
awhile before re-ording (or perhaps even taking-away) the numbers.

What do you think of the gradual approach?
-- 
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.
_
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [UPDATE] New Boot-Loader Menu -- version 1.4

[Devin Teske]

On May 7, 2011, at 8:24 PM, 兰清 wrote:

> Hi Devin,

Hi Lan,


>This loader menu is awesome!

Thank you.


> But as I opinion, items (1,6,7) and (2,3,4,5) are two different thing.

Hmmm. You're right.


>   1.Boot[Enter]
>   6.Escape to loader prompt 
>   7.Reboot
>   These options are booting action.

Interesting idea to group them that way.


>   2.ACPI Support
>   3.Boot Safe Mode
>   4.Boot Single User
>   5.Boot Verbose
>   These options are booting configures.

I follow you so far.


>  Separate them will be better, like this
> -
> | 1.Boot  |
> | 2.Prompt  |
> | 3.Reboot  |
> | 
> |
> |Configuration:   |
> | 1.ACPI Support  |
> | 2.Safe Mode |
> | 3.Single User Mode  |
> | 4.Verbose Boot Mode |
> |---|
>   Do you think so?

That's an interesting idea, and I gave it some good thought... until...

I realized that if you pressed "1" on the keyboard, would it boot or would it 
toggle "ACPI Support".

To implement a dual-menu system, either the numbers would have to go entirely, 
or the numbers would have to not overlap.

The code is not currently situated to do any of the following which would be 
required to implement what you're recommending above (either as a single-menu 
or as a dual-menu with non-overlapping menuitem keycodes):

1. Not currently possible to display two menus simultaneously (only one 
"getkey" function can be waiting for keyboard input at once, so [a] either the 
"menu-init" or "menu-create" function would need to be rewritten to dynamically 
allocate variables rather than using static identifiers, [b] the "menu-create" 
function would need to change scope to allow multiple menus to be defined each 
with their own unique properties including captions and position, and [c] the 
"menu-display" function would need to test keycodes for multiple menus that 
were generated by "menu-create" -- all of which are contained within 
/boot/menu.4th).

2. Not currently possible (with a single menu) to display a gap. Even defining 
a NULL caption will still cause the number to be printed to the left of the 
menuitem. Though I'm sure with a trivial tweak to "printmenuitem" (in 
/boot/menu.4th), checking the length identifier of the C-Addr couplet to be 
non-zero on the stack prior to dropping the dup'd menuidx to screen should 
suffice. However, even if you do that, you would then come to your next 
challenge...

3. The menu does not support tiered captions. In your example above, you've got 
"Configuration:" as a header for the remaining four options. That header would 
have to be printed manually in fourth (e.g., ``: cap ( X Y -- ) at-xy ." 
Configuration:" ; 4 17 cap'')

Numbers 2 and 3 are easy enough to overcome, but there's currently strong 
motivation to keep the menu recognizable and "in the same order" for long-time 
users. Given said motivation in-addition to the only two major short-comings of 
your proposal:

- The two menus have overlapping numbers
- The menu system does not support multiple (separate/simultaneous) menus

I would like to see general consensus from the community for separating the 
items before moving ahead with such a non-trivial change.

I thank you for your suggestion and appreciate the effort you put into it.
-- 
Cheers,
Devin


> 
> At 2011-05-05 16:20:43，"Devin Teske"  wrote:
> 
> >Hello fellow -hackers,
> >
> >I'm so very proud to offer the latest update to my new boot loader menu -- 
> >version 1.4 -- addressing ACPI detection, bringing it in-line with HEAD.
> >
> >It took some work and a few days, but I got it! Have a look below for six 
> >different displays (three different scenarios -- i386 w/ ACPI, i386 w/o 
> >ACPI, and non-i386 -- each in both B&W and Color).
> >
> >Running on i386-compatible hardware supporting ACPI:
> >B&W (standard): http://twitpic.com/4tlsin
> >Color (loader_color=YES): http://twitpic.com/4tlt6l
> >
> >Running on i386-compatible hardware lacking ACPI support:
> >B&W (standard): http://twitpic.com/4tltp0
>

Re:[UPDATE] New Boot-Loader Menu -- version 1.4

[兰清]

Hi Devin,
   This loader menu is awesome! But as I opinion, items (1,6,7) and (2,3,4,5) 
are two different thing.
1.Boot[Enter]
6.Escape to loader prompt 
7.Reboot
  These options are booting action.
2.ACPI Support
3.Boot Safe Mode
4.Boot Single User
5.Boot Verbose
  These options are booting configures. Separate them will be better, like this
-
|1.Boot  |
|2.Prompt  |
|3.Reboot  |
||
|Configuration: |
|1.ACPI Support|
|2.Safe Mode|
|3.Single User Mode|
|4.Verbose Boot Mode|

|---|
  Do you think so?

At 2011-05-05 16:20:43，"Devin Teske"  wrote:

>Hello fellow -hackers,
>
>I'm so very proud to offer the latest update to my new boot loader menu -- 
>version 1.4 -- addressing ACPI detection, bringing it in-line with HEAD.
>
>It took some work and a few days, but I got it! Have a look below for six 
>different displays (three different scenarios -- i386 w/ ACPI, i386 w/o ACPI, 
>and non-i386 -- each in both B&W and Color).
>
>Running on i386-compatible hardware supporting ACPI:
>B&W (standard): http://twitpic.com/4tlsin
>Color (loader_color=YES): http://twitpic.com/4tlt6l
>
>Running on i386-compatible hardware lacking ACPI support:
>B&W (standard): http://twitpic.com/4tltp0
>Color (loader_color=YES): http://twitpic.com/4tlu5w
>
>Running on non-i386 hardware:
>B&W (standard): http://twitpic.com/4tluio
>Color (loader_color=YES): http://twitpic.com/4tluuy
>
>This version is feature complete with HEAD and backward compatible to 
>7.0-RELEASE.
>
>I do hope you like this latest version. You can get your update at:
>
>http://druidbsd.sourceforge.net/
>   or
>http://druidbsd.sourceforge.net/download/loader_menu-1.4.tgz
>-- 
>Cheers,
>Devin Teske
>
>-> FUN STUFF <-
>-BEGIN GEEK CODE BLOCK-
>Version 3.12
>GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB$ P@$ L$ E-
>W+++ N? o? K? w@ O M++$ V- PS+>++ PE@ Y+ PGP-> t(+) 5? X(+) R(-) tv+ b+>++ DI+
>D+(++) G++ e> h r+++ z+++
>--END GEEK CODE BLOCK--
>http://www.geekcode.com/
>
>-> LEGAL DISCLAIMER <-
>This message  contains confidential  and proprietary  information
>of the sender,  and is intended only for the person(s) to whom it
>is addressed. Any use, distribution, copying or disclosure by any
>other person  is strictly prohibited.  If you have  received this
>message in error,  please notify  the e-mail sender  immediately,
>and delete the original message without making a copy.
>
>-> END TRANSMISSION <-
>
>_
>
>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.
>_
>___
>freebsd-hackers@freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: [UPDATE] New Boot-Loader Menu -- version 1.4

[Devin Teske]

> -Original Message-
> From: Warner Losh [mailto:i...@bsdimp.com]
> Sent: Friday, May 06, 2011 8:31 AM
> To: Devin Teske
> Cc: 'Ivan Voras'; freebsd-hackers@FreeBSD.org
> Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.4
> 
> 
> On May 5, 2011, at 7:21 PM, Devin Teske wrote:
> 
> >> -Original Message-
> >> From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-
> >> hack...@freebsd.org] On Behalf Of Ivan Voras
> >> Sent: Thursday, May 05, 2011 8:00 AM
> >> To: freebsd-hackers@freebsd.org
> >> Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.4
> >>
> >> On 05/05/2011 15:40, Warren Block wrote:
> >>> On Thu, 5 May 2011, Devin Teske wrote:
> >>>
> >>>> Running on i386-compatible hardware supporting ACPI:
> >>>> B&W (standard): http://twitpic.com/4tlsin
> >>>> Color (loader_color=YES): http://twitpic.com/4tlt6l
> >>>
> >>> Looks nice. Options 3, 4, and 5 could be changed to
> >>>
> >>> 3. Safe Mode
> >>> 4. Single User Mode
> >>> 5. Verbose
> >>>
> >>> On/Off or Enabled/Disabled might be bikeshedably better than Yes and
> No.
> >>
> >> If we're going to nitpick, then the style of
> >>
> >>*Enable* Safe Mode : *YES | NO*
> >>
> >> may be even better :) While at it, I'd also suggest aligning the YES |
> >> NO fields vertically for better readability.
> >>
> >> But these are minor suggestions, it is ok the way it is :)
> >>
> >
> > Suggestions are good. I'm always open to them. Both are good
> suggestions.
> >
> > It's with great undulating frivolity (think: Steve Ballmer or Billy
> Mays)
> > that I invite anyone to simply edit the decidedly Forth-free
> /boot/menu.rc
> > where the captions are configured simply as a series of carefully-named
> > environment variables. If you find something you like, report back the
> > values that you used and I'll test them out. If it's a definite
> improvement,
> > I'll definitely make the change.
> >
> > The current boot loader menu, you have to go mucking through Forth to
> change
> > the captions (which can be tricky with any stack-based language let
> alone a
> > reverse polish one such as FICL).
> 
> In general, I really like things becoming more modular.  For FreeNAS's
> boot loader, I hacked a copy and put it as a patch to the FreeNAS
> build
> 
> Warner

Awesome! Absolutely Fantastic! That's what the BSD license is all about!
(although... maybe I should have released it under the Beerware license --
with a Guinuess clause, lol).
-- 
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.
_
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [UPDATE] New Boot-Loader Menu -- version 1.4

[Warner Losh]

On May 5, 2011, at 7:21 PM, Devin Teske wrote:

>> -Original Message-
>> From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-
>> hack...@freebsd.org] On Behalf Of Ivan Voras
>> Sent: Thursday, May 05, 2011 8:00 AM
>> To: freebsd-hackers@freebsd.org
>> Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.4
>> 
>> On 05/05/2011 15:40, Warren Block wrote:
>>> On Thu, 5 May 2011, Devin Teske wrote:
>>> 
>>>> Running on i386-compatible hardware supporting ACPI:
>>>> B&W (standard): http://twitpic.com/4tlsin
>>>> Color (loader_color=YES): http://twitpic.com/4tlt6l
>>> 
>>> Looks nice. Options 3, 4, and 5 could be changed to
>>> 
>>> 3. Safe Mode
>>> 4. Single User Mode
>>> 5. Verbose
>>> 
>>> On/Off or Enabled/Disabled might be bikeshedably better than Yes and No.
>> 
>> If we're going to nitpick, then the style of
>> 
>>  *Enable* Safe Mode : *YES | NO*
>> 
>> may be even better :) While at it, I'd also suggest aligning the YES |
>> NO fields vertically for better readability.
>> 
>> But these are minor suggestions, it is ok the way it is :)
>> 
> 
> Suggestions are good. I'm always open to them. Both are good suggestions.
> 
> It's with great undulating frivolity (think: Steve Ballmer or Billy Mays)
> that I invite anyone to simply edit the decidedly Forth-free /boot/menu.rc
> where the captions are configured simply as a series of carefully-named
> environment variables. If you find something you like, report back the
> values that you used and I'll test them out. If it's a definite improvement,
> I'll definitely make the change.
> 
> The current boot loader menu, you have to go mucking through Forth to change
> the captions (which can be tricky with any stack-based language let alone a
> reverse polish one such as FICL).

In general, I really like things becoming more modular.  For FreeNAS's boot 
loader, I hacked a copy and put it as a patch to the FreeNAS build

Warner

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: [UPDATE] New Boot-Loader Menu -- version 1.4

[Devin Teske]

> -Original Message-
> From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-
> hack...@freebsd.org] On Behalf Of Ivan Voras
> Sent: Thursday, May 05, 2011 8:00 AM
> To: freebsd-hackers@freebsd.org
> Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.4
> 
> On 05/05/2011 15:40, Warren Block wrote:
> > On Thu, 5 May 2011, Devin Teske wrote:
> >
> >> Running on i386-compatible hardware supporting ACPI:
> >> B&W (standard): http://twitpic.com/4tlsin
> >> Color (loader_color=YES): http://twitpic.com/4tlt6l
> >
> > Looks nice. Options 3, 4, and 5 could be changed to
> >
> > 3. Safe Mode
> > 4. Single User Mode
> > 5. Verbose
> >
> > On/Off or Enabled/Disabled might be bikeshedably better than Yes and No.
> 
> If we're going to nitpick, then the style of
> 
>   *Enable* Safe Mode : *YES | NO*
> 
> may be even better :) While at it, I'd also suggest aligning the YES |
> NO fields vertically for better readability.
> 
> But these are minor suggestions, it is ok the way it is :)
> 

Suggestions are good. I'm always open to them. Both are good suggestions.

It's with great undulating frivolity (think: Steve Ballmer or Billy Mays)
that I invite anyone to simply edit the decidedly Forth-free /boot/menu.rc
where the captions are configured simply as a series of carefully-named
environment variables. If you find something you like, report back the
values that you used and I'll test them out. If it's a definite improvement,
I'll definitely make the change.

The current boot loader menu, you have to go mucking through Forth to change
the captions (which can be tricky with any stack-based language let alone a
reverse polish one such as FICL).
-- 
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.
_
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [UPDATE] New Boot-Loader Menu -- version 1.4

[Ivan Voras]

On 05/05/2011 15:40, Warren Block wrote:

On Thu, 5 May 2011, Devin Teske wrote:


Running on i386-compatible hardware supporting ACPI:
B&W (standard): http://twitpic.com/4tlsin
Color (loader_color=YES): http://twitpic.com/4tlt6l


Looks nice. Options 3, 4, and 5 could be changed to

3. Safe Mode
4. Single User Mode
5. Verbose

On/Off or Enabled/Disabled might be bikeshedably better than Yes and No.


If we're going to nitpick, then the style of

*Enable* Safe Mode : *YES | NO*

may be even better :) While at it, I'd also suggest aligning the YES | 
NO fields vertically for better readability.


But these are minor suggestions, it is ok the way it is :)




___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [UPDATE] New Boot-Loader Menu -- version 1.4

[Warren Block]

On Thu, 5 May 2011, Devin Teske wrote:


Running on i386-compatible hardware supporting ACPI:
B&W (standard): http://twitpic.com/4tlsin
Color (loader_color=YES): http://twitpic.com/4tlt6l


Looks nice.  Options 3, 4, and 5 could be changed to

  3. Safe Mode
  4. Single User Mode
  5. Verbose

On/Off or Enabled/Disabled might be bikeshedably better than Yes and No.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

[UPDATE] New Boot-Loader Menu -- version 1.4

[Devin Teske]

Hello fellow -hackers,

I'm so very proud to offer the latest update to my new boot loader menu -- 
version 1.4 -- addressing ACPI detection, bringing it in-line with HEAD.

It took some work and a few days, but I got it! Have a look below for six 
different displays (three different scenarios -- i386 w/ ACPI, i386 w/o ACPI, 
and non-i386 -- each in both B&W and Color).

Running on i386-compatible hardware supporting ACPI:
B&W (standard): http://twitpic.com/4tlsin
Color (loader_color=YES): http://twitpic.com/4tlt6l

Running on i386-compatible hardware lacking ACPI support:
B&W (standard): http://twitpic.com/4tltp0
Color (loader_color=YES): http://twitpic.com/4tlu5w

Running on non-i386 hardware:
B&W (standard): http://twitpic.com/4tluio
Color (loader_color=YES): http://twitpic.com/4tluuy

This version is feature complete with HEAD and backward compatible to 
7.0-RELEASE.

I do hope you like this latest version. You can get your update at:

http://druidbsd.sourceforge.net/
or
http://druidbsd.sourceforge.net/download/loader_menu-1.4.tgz
-- 
Cheers,
Devin Teske

-> FUN STUFF <-
-BEGIN GEEK CODE BLOCK-
Version 3.12
GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB$ P@$ L$ E-
W+++ N? o? K? w@ O M++$ V- PS+>++ PE@ Y+ PGP-> t(+) 5? X(+) R(-) tv+ b+>++ DI+
D+(++) G++ e> h r+++ z+++
--END GEEK CODE BLOCK--
http://www.geekcode.com/

-> LEGAL DISCLAIMER <-
This message  contains confidential  and proprietary  information
of the sender,  and is intended only for the person(s) to whom it
is addressed. Any use, distribution, copying or disclosure by any
other person  is strictly prohibited.  If you have  received this
message in error,  please notify  the e-mail sender  immediately,
and delete the original message without making a copy.

-> END TRANSMISSION <-

_

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.
_
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [UPDATE] New Boot-Loader Menu -- version 1.3

[Jason Hellenthal]

Devin,


On Wed, May 04, 2011 at 08:38:07AM -0700, Devin Teske wrote:
>
>On May 3, 2011, at 8:45 PM, Jason Hellenthal wrote:
>
>> 
>> Devin,
>> 
>> 
>> On Mon, May 02, 2011 at 08:57:05PM -0700, Devin Teske wrote:
>> [...]
>>> 
>>> loader_brand="..."
>>> 
>>> Selects the BSD brand to display. Valid values are "fbsd" (displays
>>> "FreeBSD") and "dbsd" (displays "DruidBSD"). An invalid value (such as
>>> "none") will disable the display of any brand. The brand is displayed
>>> above the dynamic menu. The default is "fbsd".
>>> 
>> [...]
>> 
>> Speaking directly toward one of the many other version announcements where 
>> you mentioned approaching -core@ in delta D). I can't see DruidBSD making 
>> it into the tree. You might want to do some work to separate that for your 
>> own personal use. Replacing it with "PC-BSD" on the other hand or allowing 
>> user supplied text to just be there without all the checking is another 
>> option.
>
>Fair enough. I'll replace "DruidBSD" with "PC-BSD". I'm sure the PC-BSD 
>community would appreciate it.
>
>Out of curiousity, are FreeBSD and PC-BSD officially affiliated in some way?

Just FreeBSD re-badged with a new installer frontend to make it easier on 
those looking to install FreeBSD as a desktop.

-- 

 Regards, (jhell)
 Jason Hellenthal



pgpwVuTb7ViC6.pgp
Description: PGP signature

Re: [RELEASE] New Boot-Loader Menu

[Devin Teske]

On May 3, 2011, at 9:06 PM, Jason Hellenthal wrote:

> 
> Devin,
> 
> 
> On Sat, Apr 30, 2011 at 08:45:14PM -0700, Devin Teske wrote:
>> 
>> On Apr 30, 2011, at 8:11 PM, Jason Hellenthal wrote:
>> 
>>> 
>>> Devin,
>>> 
>>> 
>>> On Sat, Apr 30, 2011 at 04:00:47PM -0700, Devin Teske wrote:
 
> Would be nice: "uname -v" of the kernel it will boot.
 
 That's a bit more technically challenging. I'll have another look at the
 FICL words available, but I don't recall if there was a way to crawl the
 object space of the items loaded with ``load'' (looking for the uname). I'm
 open to suggestions if you had an idea of how to do this in Forth -- else
 I'd think this would need to be a loader(8) modification.
>>> 
>>> How about forgetting a mention of unmae & ... instead look into if we
>>> can support some sort of bootcode versioning to be displayed on the
>>> screen. This would serve to be very helpful in the future when for say a
>>> new version of bootcode for ZFS has to be installed then it would be
>>> easy for announce@ to simply say "A new version of ZFS has been MFCd and
>>> requires boot version >= X. To find out your version please see the
>>> bottom right hand corner of your boot screen."
>>> 
>>> I would place a pretty good bet that loader(8) could be modified to
>>> export some sort of versioning of the bootcode to make this a easier
>>> stance for the user to gather information before a upgrade.
>> 
>> Piece of cake! If you give me a loader(8) that exports a "version" 
>> environment variable, I'll give the Forth functionality in mere seconds. 
>> It's already been developed (but was not packaged).
>> 
>> I have a module named "version.4th" which prints the value of the "version" 
>> environment variable at the bottom-right of the screen underneath the 
>> beastie logo.
>> 
>> Since you mention this, I'll add the code to the next package and if/when 
>> loader(8) ever exports a "version" environment variable, it will just 
>> magically appear. How's that sound?
>> 
> 
> Sounds perfect!

One minor adjustment... can we make that environment variable "loader_version" 
instead of "version"?

The code is already in for "loader_version". Whatever string you export into 
that environment variable will be displayed on-screen at bottom-right, 
right-justified.
-- 
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.
_
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [UPDATE] New Boot-Loader Menu -- version 1.3

[Devin Teske]

On May 3, 2011, at 8:45 PM, Jason Hellenthal wrote:

> 
> Devin,
> 
> 
> On Mon, May 02, 2011 at 08:57:05PM -0700, Devin Teske wrote:
> [...]
>> 
>> loader_brand="..."
>> 
>>  Selects the BSD brand to display. Valid values are "fbsd" (displays
>>  "FreeBSD") and "dbsd" (displays "DruidBSD"). An invalid value (such as
>>  "none") will disable the display of any brand. The brand is displayed
>>  above the dynamic menu. The default is "fbsd".
>> 
> [...]
> 
> Speaking directly toward one of the many other version announcements where 
> you mentioned approaching -core@ in delta D). I can't see DruidBSD making 
> it into the tree. You might want to do some work to separate that for your 
> own personal use. Replacing it with "PC-BSD" on the other hand or allowing 
> user supplied text to just be there without all the checking is another 
> option.

Fair enough. I'll replace "DruidBSD" with "PC-BSD". I'm sure the PC-BSD 
community would appreciate it.

Out of curiousity, are FreeBSD and PC-BSD officially affiliated in some way?
-- 
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.
_
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [UPDATE] New Boot-Loader Menu -- version 1.3

[Emanuel Haupt]

Devin Teske  wrote:
> Hey all,
> 
> Proud to bring you version 1.3 which completes the followup
> suggestions made by Olivier Smedts (use autoboot_delay instead of
> loader_menu_timeout and change dc_seconds to loader_delay) and a
> couple other minor enhancements/fixes.
> 
> I think that brings everything up to speed with the phenomenal
> feedback provided so far. Really, thank you all very much.
> 
> Get your update at http://druidbsd.sf.net/ or
> http://druidbsd.sourceforge.net/download/loader_menu-1.3.tgz

Devin, have you thought about writing a port [1]? I'd be happy to
review it:

[1] 
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/own-port.html

Emanuel
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RELEASE] New Boot-Loader Menu

[Jason Hellenthal]

Devin,


On Sat, Apr 30, 2011 at 08:45:14PM -0700, Devin Teske wrote:
>
>On Apr 30, 2011, at 8:11 PM, Jason Hellenthal wrote:
>
>> 
>> Devin,
>> 
>> 
>> On Sat, Apr 30, 2011 at 04:00:47PM -0700, Devin Teske wrote:
>>> 
 Would be nice: "uname -v" of the kernel it will boot.
>>> 
>>> That's a bit more technically challenging. I'll have another look at the
>>> FICL words available, but I don't recall if there was a way to crawl the
>>> object space of the items loaded with ``load'' (looking for the uname). I'm
>>> open to suggestions if you had an idea of how to do this in Forth -- else
>>> I'd think this would need to be a loader(8) modification.
>> 
>> How about forgetting a mention of unmae & ... instead look into if we
>> can support some sort of bootcode versioning to be displayed on the
>> screen. This would serve to be very helpful in the future when for say a
>> new version of bootcode for ZFS has to be installed then it would be
>> easy for announce@ to simply say "A new version of ZFS has been MFCd and
>> requires boot version >= X. To find out your version please see the
>> bottom right hand corner of your boot screen."
>> 
>> I would place a pretty good bet that loader(8) could be modified to
>> export some sort of versioning of the bootcode to make this a easier
>> stance for the user to gather information before a upgrade.
>
>Piece of cake! If you give me a loader(8) that exports a "version" environment 
>variable, I'll give the Forth functionality in mere seconds. It's already been 
>developed (but was not packaged).
>
>I have a module named "version.4th" which prints the value of the "version" 
>environment variable at the bottom-right of the screen underneath the beastie 
>logo.
>
>Since you mention this, I'll add the code to the next package and if/when 
>loader(8) ever exports a "version" environment variable, it will just 
>magically appear. How's that sound?
>

Sounds perfect!

-- 

 Regards, (jhell)
 Jason Hellenthal



pgpjXdkxfm4pB.pgp
Description: PGP signature

Re: [UPDATE] New Boot-Loader Menu -- version 1.3

[Jason Hellenthal]

Devin,


On Mon, May 02, 2011 at 08:57:05PM -0700, Devin Teske wrote:
[...]
>
>loader_brand="..."
>
>   Selects the BSD brand to display. Valid values are "fbsd" (displays
>   "FreeBSD") and "dbsd" (displays "DruidBSD"). An invalid value (such as
>   "none") will disable the display of any brand. The brand is displayed
>   above the dynamic menu. The default is "fbsd".
>
[...]

Speaking directly toward one of the many other version announcements where 
you mentioned approaching -core@ in delta D). I can't see DruidBSD making 
it into the tree. You might want to do some work to separate that for your 
own personal use. Replacing it with "PC-BSD" on the other hand or allowing 
user supplied text to just be there without all the checking is another 
option.


-- 

 Regards, (jhell)
 Jason Hellenthal



pgpwVTTnUBCzG.pgp
Description: PGP signature

Re: [UPDATE] New Boot-Loader Menu -- version 1.1

[John Baldwin]

On Tuesday, May 03, 2011 5:22:20 pm Devin Teske wrote:
> > -Original Message-
> > From: John Baldwin [mailto:j...@freebsd.org]
> > Sent: Tuesday, May 03, 2011 2:01 PM
> > To: Devin Teske
> > Cc: freebsd-hackers@freebsd.org
> > Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1
> > 
> > On Tuesday, May 03, 2011 4:47:26 pm Devin Teske wrote:
> > > > -Original Message-
> > > > From: John Baldwin [mailto:j...@freebsd.org]
> > > > Sent: Tuesday, May 03, 2011 1:36 PM
> > > > To: Devin Teske
> > > > Cc: freebsd-hackers@freebsd.org
> > > > Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1
> > > >
> > > > On Tuesday, May 03, 2011 4:17:23 pm Devin Teske wrote:
> > > > > > -Original Message-
> > > > > > From: John Baldwin [mailto:j...@freebsd.org]
> > > > > > Sent: Tuesday, May 03, 2011 12:20 PM
> > > > > > To: Devin Teske
> > > > > > Cc: freebsd-hackers@freebsd.org
> > > > > > Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1
> > > > > >
> > > > > > On Tuesday, May 03, 2011 2:57:34 pm Devin Teske wrote:
> > > > > > > > From: John Baldwin [mailto:j...@freebsd.org]
> > > > > > > > Sent: Tuesday, May 03, 2011 10:33 AM
> > > > > > > > To: Devin Teske
> > > > > > > > Cc: freebsd-hackers@freebsd.org; Olivier SMEDTS
> > > > > > > > Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1
> > > > > > > >
> > > > > > > > On Tuesday, May 03, 2011 12:31:14 pm Devin Teske wrote:
> > > > > > > > >
> > > > > > > > > On May 3, 2011, at 4:45 AM, John Baldwin wrote:
> > > > > > > > >
> > > > > > > > > > On Monday, May 02, 2011 8:48:31 pm Devin Teske wrote:
> > > > > > > > > > > This version (1.1) works nearly identically to the
> > > > > > > > > > > standard menu that ships with FreeBSD in that it
> > > > > > > > > > > detects whether ACPI is enabled (truth be told, I
> > > > > > > > > > > actually re-used the
> > > > "acpienabled?"
> > > > > > > > > > > function verbatim from /boot/beastie.4th by Scott Long
> > > > > > > > > > > and Aleksander Fafula). The ACPI detection of my boot
> > > > > > > > > > > loader (version
> > > > > > > > > > > 1.1 or higher) should be identical to the detection of
> > > > > > > > > > > the current boot-loader.
> > > > > > > > >
> > > > > > > > > Ugh. By "current", I meant 8.1-RELEASE (wasn't expecting
> > > > > > > > > this stuff to be different in HEAD, which it is).
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > Err, note that the acpienabled stuff is all different in
> > > > > > > > > > HEAD than in 7/8 since acpi.ko no longer exists.  You
> > > > > > > > > > should use the scheme from HEAD for handling ACPI
> > > > > > > > > > present vs ACPI
> > > > enabled/disabled.
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > John Baldwin
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Ok, I see the new "acpipresent?" word (which replaces the
> > > "arch-i386"
> > > > > > > > > environment-test). Does this imply that we're going to
> > > > > > > > > support ACPI on
> > > > > > > > > non-i386 platforms (or already do)?
> > > > > > > >
> > > > > > > > amd64 and ia64 have always supported ACPI.  ia64 effectively
> > > > > > > > requires
> > > it.
> > > > > > > > However, "hint.acpi.0.rsdp" is set by biosacpi.c in the i386
> > > > > > > > loader bits, so other platforms will not set it, so the
> > > > > > > > arch-i386 test is no longer
> > 

RE: [UPDATE] New Boot-Loader Menu -- version 1.1

[Devin Teske]

> -Original Message-
> From: John Baldwin [mailto:j...@freebsd.org]
> Sent: Tuesday, May 03, 2011 2:01 PM
> To: Devin Teske
> Cc: freebsd-hackers@freebsd.org
> Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1
> 
> On Tuesday, May 03, 2011 4:47:26 pm Devin Teske wrote:
> > > -Original Message-
> > > From: John Baldwin [mailto:j...@freebsd.org]
> > > Sent: Tuesday, May 03, 2011 1:36 PM
> > > To: Devin Teske
> > > Cc: freebsd-hackers@freebsd.org
> > > Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1
> > >
> > > On Tuesday, May 03, 2011 4:17:23 pm Devin Teske wrote:
> > > > > -Original Message-
> > > > > From: John Baldwin [mailto:j...@freebsd.org]
> > > > > Sent: Tuesday, May 03, 2011 12:20 PM
> > > > > To: Devin Teske
> > > > > Cc: freebsd-hackers@freebsd.org
> > > > > Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1
> > > > >
> > > > > On Tuesday, May 03, 2011 2:57:34 pm Devin Teske wrote:
> > > > > > > From: John Baldwin [mailto:j...@freebsd.org]
> > > > > > > Sent: Tuesday, May 03, 2011 10:33 AM
> > > > > > > To: Devin Teske
> > > > > > > Cc: freebsd-hackers@freebsd.org; Olivier SMEDTS
> > > > > > > Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1
> > > > > > >
> > > > > > > On Tuesday, May 03, 2011 12:31:14 pm Devin Teske wrote:
> > > > > > > >
> > > > > > > > On May 3, 2011, at 4:45 AM, John Baldwin wrote:
> > > > > > > >
> > > > > > > > > On Monday, May 02, 2011 8:48:31 pm Devin Teske wrote:
> > > > > > > > > > This version (1.1) works nearly identically to the
> > > > > > > > > > standard menu that ships with FreeBSD in that it
> > > > > > > > > > detects whether ACPI is enabled (truth be told, I
> > > > > > > > > > actually re-used the
> > > "acpienabled?"
> > > > > > > > > > function verbatim from /boot/beastie.4th by Scott Long
> > > > > > > > > > and Aleksander Fafula). The ACPI detection of my boot
> > > > > > > > > > loader (version
> > > > > > > > > > 1.1 or higher) should be identical to the detection of
> > > > > > > > > > the current boot-loader.
> > > > > > > >
> > > > > > > > Ugh. By "current", I meant 8.1-RELEASE (wasn't expecting
> > > > > > > > this stuff to be different in HEAD, which it is).
> > > > > > > >
> > > > > > > >
> > > > > > > > > Err, note that the acpienabled stuff is all different in
> > > > > > > > > HEAD than in 7/8 since acpi.ko no longer exists.  You
> > > > > > > > > should use the scheme from HEAD for handling ACPI
> > > > > > > > > present vs ACPI
> > > enabled/disabled.
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > John Baldwin
> > > > > > > >
> > > > > > > >
> > > > > > > > Ok, I see the new "acpipresent?" word (which replaces the
> > "arch-i386"
> > > > > > > > environment-test). Does this imply that we're going to
> > > > > > > > support ACPI on
> > > > > > > > non-i386 platforms (or already do)?
> > > > > > >
> > > > > > > amd64 and ia64 have always supported ACPI.  ia64 effectively
> > > > > > > requires
> > it.
> > > > > > > However, "hint.acpi.0.rsdp" is set by biosacpi.c in the i386
> > > > > > > loader bits, so other platforms will not set it, so the
> > > > > > > arch-i386 test is no longer
> > > > > > needed.
> > > > > >
> > > > > > If "hint.acpi.0.rsdp" is only set in the i386 pieces, wouldn't
> > > > > > that imply that the "acpipresent?" would return FALSE on IA64?
> > > > >
> > > > > Yes.  Right now the ACPI menu item is not displayed on ia64 and
> > > > > it never

Re: [UPDATE] New Boot-Loader Menu -- version 1.1

[John Baldwin]

On Tuesday, May 03, 2011 4:47:26 pm Devin Teske wrote:
> > -Original Message-
> > From: John Baldwin [mailto:j...@freebsd.org]
> > Sent: Tuesday, May 03, 2011 1:36 PM
> > To: Devin Teske
> > Cc: freebsd-hackers@freebsd.org
> > Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1
> > 
> > On Tuesday, May 03, 2011 4:17:23 pm Devin Teske wrote:
> > > > -Original Message-
> > > > From: John Baldwin [mailto:j...@freebsd.org]
> > > > Sent: Tuesday, May 03, 2011 12:20 PM
> > > > To: Devin Teske
> > > > Cc: freebsd-hackers@freebsd.org
> > > > Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1
> > > >
> > > > On Tuesday, May 03, 2011 2:57:34 pm Devin Teske wrote:
> > > > > > From: John Baldwin [mailto:j...@freebsd.org]
> > > > > > Sent: Tuesday, May 03, 2011 10:33 AM
> > > > > > To: Devin Teske
> > > > > > Cc: freebsd-hackers@freebsd.org; Olivier SMEDTS
> > > > > > Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1
> > > > > >
> > > > > > On Tuesday, May 03, 2011 12:31:14 pm Devin Teske wrote:
> > > > > > >
> > > > > > > On May 3, 2011, at 4:45 AM, John Baldwin wrote:
> > > > > > >
> > > > > > > > On Monday, May 02, 2011 8:48:31 pm Devin Teske wrote:
> > > > > > > > > This version (1.1) works nearly identically to the
> > > > > > > > > standard menu that ships with FreeBSD in that it detects
> > > > > > > > > whether ACPI is enabled (truth be told, I actually re-used the
> > "acpienabled?"
> > > > > > > > > function verbatim from /boot/beastie.4th by Scott Long and
> > > > > > > > > Aleksander Fafula). The ACPI detection of my boot loader
> > > > > > > > > (version
> > > > > > > > > 1.1 or higher) should be identical to the detection of the
> > > > > > > > > current boot-loader.
> > > > > > >
> > > > > > > Ugh. By "current", I meant 8.1-RELEASE (wasn't expecting this
> > > > > > > stuff to be different in HEAD, which it is).
> > > > > > >
> > > > > > >
> > > > > > > > Err, note that the acpienabled stuff is all different in
> > > > > > > > HEAD than in 7/8 since acpi.ko no longer exists.  You should
> > > > > > > > use the scheme from HEAD for handling ACPI present vs ACPI
> > enabled/disabled.
> > > > > > > >
> > > > > > > > --
> > > > > > > > John Baldwin
> > > > > > >
> > > > > > >
> > > > > > > Ok, I see the new "acpipresent?" word (which replaces the
> "arch-i386"
> > > > > > > environment-test). Does this imply that we're going to support
> > > > > > > ACPI on
> > > > > > > non-i386 platforms (or already do)?
> > > > > >
> > > > > > amd64 and ia64 have always supported ACPI.  ia64 effectively 
> > > > > > requires
> it.
> > > > > > However, "hint.acpi.0.rsdp" is set by biosacpi.c in the i386
> > > > > > loader bits, so other platforms will not set it, so the
> > > > > > arch-i386 test is no longer
> > > > > needed.
> > > > >
> > > > > If "hint.acpi.0.rsdp" is only set in the i386 pieces, wouldn't
> > > > > that imply that the "acpipresent?" would return FALSE on IA64?
> > > >
> > > > Yes.  Right now the ACPI menu item is not displayed on ia64 and it
> > > > never has been.  You can't actually boot IA64 with ACPI disabled, so
> > > > there's no reason
> > > for it
> > > > to be in the menu.
> > >
> > > This raises a concern for my menu. Unlike the current menu, which
> > > blanks-out menuitem #2 for IA64, I've chosen instead to insert an
> > > inoperative menuitem with the text "ACPI Support: N/A".
> > 
> > Hmm, I think you should just leave the menu item blank or not listed.  It
> doesn't
> > make sense to see a knob about ACPI support on a ppc box for example, and
> > other platforms may grow platform-specific knobs in the future as well.
> > 
> > The current menu item is only blank as a hack to avoid renumbering the 
> > items.
> > If you are already changing that around, then I'd just leave it out 
> > altogether
> > unless ACPI is detected by the loader.
> > 
> 
> I too avoid renumbering of the items.
> 
> Having never actually booted a PPC or IA64 FreeBSD installation... is it the
> case that the numbers displayed jump from 1 to 3 (no blank line in-between 1 
> and
> 3, correct)?

Actually, I think PPC/IA64, etc. do not display the ACPI menu item at all and
they are numbered differently from i386 and amd64.  The ACPI menu item is only
blank if ACPI is not present on i386 and amd64.

-- 
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: [UPDATE] New Boot-Loader Menu -- version 1.1

[Devin Teske]

> -Original Message-
> From: John Baldwin [mailto:j...@freebsd.org]
> Sent: Tuesday, May 03, 2011 1:36 PM
> To: Devin Teske
> Cc: freebsd-hackers@freebsd.org
> Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1
> 
> On Tuesday, May 03, 2011 4:17:23 pm Devin Teske wrote:
> > > -Original Message-
> > > From: John Baldwin [mailto:j...@freebsd.org]
> > > Sent: Tuesday, May 03, 2011 12:20 PM
> > > To: Devin Teske
> > > Cc: freebsd-hackers@freebsd.org
> > > Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1
> > >
> > > On Tuesday, May 03, 2011 2:57:34 pm Devin Teske wrote:
> > > > > From: John Baldwin [mailto:j...@freebsd.org]
> > > > > Sent: Tuesday, May 03, 2011 10:33 AM
> > > > > To: Devin Teske
> > > > > Cc: freebsd-hackers@freebsd.org; Olivier SMEDTS
> > > > > Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1
> > > > >
> > > > > On Tuesday, May 03, 2011 12:31:14 pm Devin Teske wrote:
> > > > > >
> > > > > > On May 3, 2011, at 4:45 AM, John Baldwin wrote:
> > > > > >
> > > > > > > On Monday, May 02, 2011 8:48:31 pm Devin Teske wrote:
> > > > > > > > This version (1.1) works nearly identically to the
> > > > > > > > standard menu that ships with FreeBSD in that it detects
> > > > > > > > whether ACPI is enabled (truth be told, I actually re-used the
> "acpienabled?"
> > > > > > > > function verbatim from /boot/beastie.4th by Scott Long and
> > > > > > > > Aleksander Fafula). The ACPI detection of my boot loader
> > > > > > > > (version
> > > > > > > > 1.1 or higher) should be identical to the detection of the
> > > > > > > > current boot-loader.
> > > > > >
> > > > > > Ugh. By "current", I meant 8.1-RELEASE (wasn't expecting this
> > > > > > stuff to be different in HEAD, which it is).
> > > > > >
> > > > > >
> > > > > > > Err, note that the acpienabled stuff is all different in
> > > > > > > HEAD than in 7/8 since acpi.ko no longer exists.  You should
> > > > > > > use the scheme from HEAD for handling ACPI present vs ACPI
> enabled/disabled.
> > > > > > >
> > > > > > > --
> > > > > > > John Baldwin
> > > > > >
> > > > > >
> > > > > > Ok, I see the new "acpipresent?" word (which replaces the
"arch-i386"
> > > > > > environment-test). Does this imply that we're going to support
> > > > > > ACPI on
> > > > > > non-i386 platforms (or already do)?
> > > > >
> > > > > amd64 and ia64 have always supported ACPI.  ia64 effectively requires
it.
> > > > > However, "hint.acpi.0.rsdp" is set by biosacpi.c in the i386
> > > > > loader bits, so other platforms will not set it, so the
> > > > > arch-i386 test is no longer
> > > > needed.
> > > >
> > > > If "hint.acpi.0.rsdp" is only set in the i386 pieces, wouldn't
> > > > that imply that the "acpipresent?" would return FALSE on IA64?
> > >
> > > Yes.  Right now the ACPI menu item is not displayed on ia64 and it
> > > never has been.  You can't actually boot IA64 with ACPI disabled, so
> > > there's no reason
> > for it
> > > to be in the menu.
> >
> > This raises a concern for my menu. Unlike the current menu, which
> > blanks-out menuitem #2 for IA64, I've chosen instead to insert an
> > inoperative menuitem with the text "ACPI Support: N/A".
> 
> Hmm, I think you should just leave the menu item blank or not listed.  It
doesn't
> make sense to see a knob about ACPI support on a ppc box for example, and
> other platforms may grow platform-specific knobs in the future as well.
> 
> The current menu item is only blank as a hack to avoid renumbering the items.
> If you are already changing that around, then I'd just leave it out altogether
> unless ACPI is detected by the loader.
> 

I too avoid renumbering of the items.

Having never actually booted a PPC or IA64 FreeBSD installation... is it the
case that the numbers displayed jump from 1 to 3 (no blank line in-between 1 and
3, correct)?

I think that sounds like the sensible thing to do.
-- 
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.
_
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [UPDATE] New Boot-Loader Menu -- version 1.1

[John Baldwin]

On Tuesday, May 03, 2011 4:17:23 pm Devin Teske wrote:
> > -Original Message-
> > From: John Baldwin [mailto:j...@freebsd.org]
> > Sent: Tuesday, May 03, 2011 12:20 PM
> > To: Devin Teske
> > Cc: freebsd-hackers@freebsd.org
> > Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1
> > 
> > On Tuesday, May 03, 2011 2:57:34 pm Devin Teske wrote:
> > > > From: John Baldwin [mailto:j...@freebsd.org]
> > > > Sent: Tuesday, May 03, 2011 10:33 AM
> > > > To: Devin Teske
> > > > Cc: freebsd-hackers@freebsd.org; Olivier SMEDTS
> > > > Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1
> > > >
> > > > On Tuesday, May 03, 2011 12:31:14 pm Devin Teske wrote:
> > > > >
> > > > > On May 3, 2011, at 4:45 AM, John Baldwin wrote:
> > > > >
> > > > > > On Monday, May 02, 2011 8:48:31 pm Devin Teske wrote:
> > > > > > > This version (1.1) works nearly identically to the standard
> > > > > > > menu that ships with FreeBSD in that it detects whether ACPI
> > > > > > > is enabled (truth be told, I actually re-used the "acpienabled?"
> > > > > > > function verbatim from /boot/beastie.4th by Scott Long and
> > > > > > > Aleksander Fafula). The ACPI detection of my boot loader
> > > > > > > (version
> > > > > > > 1.1 or higher) should be identical to the detection of the
> > > > > > > current boot-loader.
> > > > >
> > > > > Ugh. By "current", I meant 8.1-RELEASE (wasn't expecting this
> > > > > stuff to be different in HEAD, which it is).
> > > > >
> > > > >
> > > > > > Err, note that the acpienabled stuff is all different in HEAD
> > > > > > than in 7/8 since acpi.ko no longer exists.  You should use the
> > > > > > scheme from HEAD for handling ACPI present vs ACPI enabled/disabled.
> > > > > >
> > > > > > --
> > > > > > John Baldwin
> > > > >
> > > > >
> > > > > Ok, I see the new "acpipresent?" word (which replaces the "arch-i386"
> > > > > environment-test). Does this imply that we're going to support
> > > > > ACPI on
> > > > > non-i386 platforms (or already do)?
> > > >
> > > > amd64 and ia64 have always supported ACPI.  ia64 effectively requires 
> > > > it.
> > > > However, "hint.acpi.0.rsdp" is set by biosacpi.c in the i386 loader
> > > > bits, so other platforms will not set it, so the arch-i386 test is
> > > > no longer
> > > needed.
> > >
> > > If "hint.acpi.0.rsdp" is only set in the i386 pieces, wouldn't that
> > > imply that the "acpipresent?" would return FALSE on IA64?
> > 
> > Yes.  Right now the ACPI menu item is not displayed on ia64 and it never has
> > been.  You can't actually boot IA64 with ACPI disabled, so there's no reason
> for it
> > to be in the menu.
> 
> This raises a concern for my menu. Unlike the current menu, which blanks-out
> menuitem #2 for IA64, I've chosen instead to insert an inoperative menuitem 
> with
> the text "ACPI Support: N/A".

Hmm, I think you should just leave the menu item blank or not listed.  It
doesn't make sense to see a knob about ACPI support on a ppc box for example,
and other platforms may grow platform-specific knobs in the future as well.

The current menu item is only blank as a hack to avoid renumbering the items.
If you are already changing that around, then I'd just leave it out altogether
unless ACPI is detected by the loader.

> So what do you think I should do?
> 
> a. Rewrite both "acpipresent?" and "acpienabled?" to be backward compatible 
> with
> 6.x/older or
> b. embrace the future and simply warn about backward compatibility (or lack
> thereof) with respect to ACPI support.
> 
> NOTE: Route (a) may not be possible unless the loader_version was bumped at 
> the
> same time that hint.acpi.0.rsdp was added.

(a) is not possible for the reason you mention.  I wouldn't worry about 
supporting
6.x at this point, esp. if it is going to be a pain.

-- 
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: [UPDATE] New Boot-Loader Menu -- version 1.1

[Devin Teske]

> -Original Message-
> From: John Baldwin [mailto:j...@freebsd.org]
> Sent: Tuesday, May 03, 2011 12:20 PM
> To: Devin Teske
> Cc: freebsd-hackers@freebsd.org
> Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1
> 
> On Tuesday, May 03, 2011 2:57:34 pm Devin Teske wrote:
> > > From: John Baldwin [mailto:j...@freebsd.org]
> > > Sent: Tuesday, May 03, 2011 10:33 AM
> > > To: Devin Teske
> > > Cc: freebsd-hackers@freebsd.org; Olivier SMEDTS
> > > Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1
> > >
> > > On Tuesday, May 03, 2011 12:31:14 pm Devin Teske wrote:
> > > >
> > > > On May 3, 2011, at 4:45 AM, John Baldwin wrote:
> > > >
> > > > > On Monday, May 02, 2011 8:48:31 pm Devin Teske wrote:
> > > > > > This version (1.1) works nearly identically to the standard
> > > > > > menu that ships with FreeBSD in that it detects whether ACPI
> > > > > > is enabled (truth be told, I actually re-used the "acpienabled?"
> > > > > > function verbatim from /boot/beastie.4th by Scott Long and
> > > > > > Aleksander Fafula). The ACPI detection of my boot loader
> > > > > > (version
> > > > > > 1.1 or higher) should be identical to the detection of the
> > > > > > current boot-loader.
> > > >
> > > > Ugh. By "current", I meant 8.1-RELEASE (wasn't expecting this
> > > > stuff to be different in HEAD, which it is).
> > > >
> > > >
> > > > > Err, note that the acpienabled stuff is all different in HEAD
> > > > > than in 7/8 since acpi.ko no longer exists.  You should use the
> > > > > scheme from HEAD for handling ACPI present vs ACPI enabled/disabled.
> > > > >
> > > > > --
> > > > > John Baldwin
> > > >
> > > >
> > > > Ok, I see the new "acpipresent?" word (which replaces the "arch-i386"
> > > > environment-test). Does this imply that we're going to support
> > > > ACPI on
> > > > non-i386 platforms (or already do)?
> > >
> > > amd64 and ia64 have always supported ACPI.  ia64 effectively requires it.
> > > However, "hint.acpi.0.rsdp" is set by biosacpi.c in the i386 loader
> > > bits, so other platforms will not set it, so the arch-i386 test is
> > > no longer
> > needed.
> >
> > If "hint.acpi.0.rsdp" is only set in the i386 pieces, wouldn't that
> > imply that the "acpipresent?" would return FALSE on IA64?
> 
> Yes.  Right now the ACPI menu item is not displayed on ia64 and it never has
> been.  You can't actually boot IA64 with ACPI disabled, so there's no reason
for it
> to be in the menu.

This raises a concern for my menu. Unlike the current menu, which blanks-out
menuitem #2 for IA64, I've chosen instead to insert an inoperative menuitem with
the text "ACPI Support: N/A".

What do you think would be an appropriate stand-in? Perhaps "ACPI Support:
Enabled" (simply assume that it's enabled and do nothing if the user attempts to
disable it) or "ACPI Support:" with no text (or maybe what I've got right now --
"ACPI Support: N/A" -- is already acceptable)?

> 
> > > > I also see the rewritten "acpienabled?" word. Nice. I'll slurp it
> > > > in to make my ACPI detection the same as HEAD.
> > > >
> > > > I also performed some backward compatibility tests. Looks like
> > > > this will be backward compatible with 8.1-RELEASE (loader_version ==
11).
> > > > However, the code in HEAD appears to not work in 8.0-RELEASE
> > > > (loader_version == 8).
> > >
> > > Hmm, which part does not work in 8.0?  arch-i386 has existed since
> > > at least 4.x I thought, and the ACPI bits have been setting
> > > hint.acpi.0.rsdp since 7.0 (sys/boot/i386/libi386/biosacpi.c CVS rev
> > > 1.12
> > added it).
> > >
> > > --
> > > John Baldwin
> >
> > I've got this 8.0-STABLE box. I don't know exactly when it was
> > installed, but /boot/loader has a timestamp from June 2010 and when I
> execute:
> >
> > s" loader_version" environment? drop .
> >
> > I get "8", whereas when I boot the same exact hardware with
> > 8.1-RELEASE, I get "11".
> >
> > When I boot 8.0-STABLE (loader_version 8), I do not have "hint.acpi

Re: [UPDATE] New Boot-Loader Menu -- version 1.1

[John Baldwin]

On Tuesday, May 03, 2011 2:57:34 pm Devin Teske wrote:
> > From: John Baldwin [mailto:j...@freebsd.org]
> > Sent: Tuesday, May 03, 2011 10:33 AM
> > To: Devin Teske
> > Cc: freebsd-hackers@freebsd.org; Olivier SMEDTS
> > Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1
> >
> > On Tuesday, May 03, 2011 12:31:14 pm Devin Teske wrote:
> > >
> > > On May 3, 2011, at 4:45 AM, John Baldwin wrote:
> > >
> > > > On Monday, May 02, 2011 8:48:31 pm Devin Teske wrote:
> > > > > This version (1.1) works nearly identically to the standard menu
> > > > > that ships with FreeBSD in that it detects whether ACPI is
> > > > > enabled (truth be told, I actually re-used the "acpienabled?"
> > > > > function verbatim from /boot/beastie.4th by Scott Long and
> > > > > Aleksander Fafula). The ACPI detection of my boot loader (version
> > > > > 1.1 or higher) should be identical to the detection of the current
> > > > > boot-loader.
> > >
> > > Ugh. By "current", I meant 8.1-RELEASE (wasn't expecting this stuff
> > > to be different in HEAD, which it is).
> > >
> > >
> > > > Err, note that the acpienabled stuff is all different in HEAD than
> > > > in 7/8 since acpi.ko no longer exists.  You should use the scheme
> > > > from HEAD for handling ACPI present vs ACPI enabled/disabled.
> > > >
> > > > --
> > > > John Baldwin
> > >
> > >
> > > Ok, I see the new "acpipresent?" word (which replaces the "arch-i386"
> > > environment-test). Does this imply that we're going to support ACPI on
> > > non-i386 platforms (or already do)?
> >
> > amd64 and ia64 have always supported ACPI.  ia64 effectively requires it.
> > However, "hint.acpi.0.rsdp" is set by biosacpi.c in the i386 loader
> > bits, so other platforms will not set it, so the arch-i386 test is no longer
> needed.
> 
> If "hint.acpi.0.rsdp" is only set in the i386 pieces, wouldn't that imply that
> the
> "acpipresent?" would return FALSE on IA64?

Yes.  Right now the ACPI menu item is not displayed on ia64 and it never has
been.  You can't actually boot IA64 with ACPI disabled, so there's no reason
for it to be in the menu.

> > > I also see the rewritten "acpienabled?" word. Nice. I'll slurp it in
> > > to make my ACPI detection the same as HEAD.
> > >
> > > I also performed some backward compatibility tests. Looks like this
> > > will be backward compatible with 8.1-RELEASE (loader_version == 11).
> > > However, the code in HEAD appears to not work in 8.0-RELEASE
> > > (loader_version == 8).
> >
> > Hmm, which part does not work in 8.0?  arch-i386 has existed since at
> > least 4.x I thought, and the ACPI bits have been setting
> > hint.acpi.0.rsdp since 7.0 (sys/boot/i386/libi386/biosacpi.c CVS rev 1.12
> added it).
> >
> > --
> > John Baldwin
> 
> I've got this 8.0-STABLE box. I don't know exactly when it was installed, but
> /boot/loader has a timestamp from June 2010 and when I execute:
> 
>   s" loader_version" environment? drop .
> 
> I get "8", whereas when I boot the same exact hardware with 8.1-RELEASE, I get
> "11".
> 
> When I boot 8.0-STABLE (loader_version 8), I do not have "hint.acpi.0.rsdp"
> whereas if I boot 8.1-RELEASE (loader_version 11), I do get 
> "hint.acpi.0.rsdp".
> (NOTE: this is on the exact same hardware, without changing any BIOS settings
> between boots).
> 
> Is it possible that my 8.0-STABLE has a loader that is older than 7.0-RELEASE?
> I'm
> trying to figure out why this 8.0-STABLE box is not setting hint.acpi.0.rsdp.

What is the output of 'kenv | grep acpi' from your old loader?

Hmm, sys/boot/i386/loader/version was bumped to 1.1 in 5.0 release.  It was
bumped to 1.0 in 5.0-CURRENT.  It was last 0.8 (so "8") in 4.x.

-- 
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: [UPDATE] New Boot-Loader Menu -- version 1.1

[Devin Teske]

> From: John Baldwin [mailto:j...@freebsd.org]
> Sent: Tuesday, May 03, 2011 10:33 AM
> To: Devin Teske
> Cc: freebsd-hackers@freebsd.org; Olivier SMEDTS
> Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1
>
> On Tuesday, May 03, 2011 12:31:14 pm Devin Teske wrote:
> >
> > On May 3, 2011, at 4:45 AM, John Baldwin wrote:
> >
> > > On Monday, May 02, 2011 8:48:31 pm Devin Teske wrote:
> > > > This version (1.1) works nearly identically to the standard menu
> > > > that ships with FreeBSD in that it detects whether ACPI is
> > > > enabled (truth be told, I actually re-used the "acpienabled?"
> > > > function verbatim from /boot/beastie.4th by Scott Long and
> > > > Aleksander Fafula). The ACPI detection of my boot loader (version
> > > > 1.1 or higher) should be identical to the detection of the current
> > > > boot-loader.
> >
> > Ugh. By "current", I meant 8.1-RELEASE (wasn't expecting this stuff
> > to be different in HEAD, which it is).
> >
> >
> > > Err, note that the acpienabled stuff is all different in HEAD than
> > > in 7/8 since acpi.ko no longer exists.  You should use the scheme
> > > from HEAD for handling ACPI present vs ACPI enabled/disabled.
> > >
> > > --
> > > John Baldwin
> >
> >
> > Ok, I see the new "acpipresent?" word (which replaces the "arch-i386"
> > environment-test). Does this imply that we're going to support ACPI on
> > non-i386 platforms (or already do)?
>
> amd64 and ia64 have always supported ACPI.  ia64 effectively requires it.
> However, "hint.acpi.0.rsdp" is set by biosacpi.c in the i386 loader
> bits, so other platforms will not set it, so the arch-i386 test is no longer
needed.

If "hint.acpi.0.rsdp" is only set in the i386 pieces, wouldn't that imply that
the
"acpipresent?" would return FALSE on IA64?


> > I also see the rewritten "acpienabled?" word. Nice. I'll slurp it in
> > to make my ACPI detection the same as HEAD.
> >
> > I also performed some backward compatibility tests. Looks like this
> > will be backward compatible with 8.1-RELEASE (loader_version == 11).
> > However, the code in HEAD appears to not work in 8.0-RELEASE
> > (loader_version == 8).
>
> Hmm, which part does not work in 8.0?  arch-i386 has existed since at
> least 4.x I thought, and the ACPI bits have been setting
> hint.acpi.0.rsdp since 7.0 (sys/boot/i386/libi386/biosacpi.c CVS rev 1.12
added it).
>
> --
> John Baldwin

I've got this 8.0-STABLE box. I don't know exactly when it was installed, but
/boot/loader has a timestamp from June 2010 and when I execute:

s" loader_version" environment? drop .

I get "8", whereas when I boot the same exact hardware with 8.1-RELEASE, I get
"11".

When I boot 8.0-STABLE (loader_version 8), I do not have "hint.acpi.0.rsdp"
whereas if I boot 8.1-RELEASE (loader_version 11), I do get "hint.acpi.0.rsdp".
(NOTE: this is on the exact same hardware, without changing any BIOS settings
between boots).

Is it possible that my 8.0-STABLE has a loader that is older than 7.0-RELEASE?
I'm
trying to figure out why this 8.0-STABLE box is not setting hint.acpi.0.rsdp.
--
Cheers,
Devin Teske

-> FUN STUFF <-
-BEGIN GEEK CODE BLOCK-
Version 3.12
GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB$ P@$ L$ E-
W+++ N? o? K? w@ O M++$ V- PS+>++ PE@ Y+ PGP-> t(+) 5? X(+) R(-) tv+ W+++ b+>++
DI+
D+(++) G++ e> h r+++ z+++
--END GEEK CODE BLOCK--
Learn about the "Geek Code": http://www.geekcode.com/

-> LEGAL DISCLAIMER <-
This message  contains confidential  and proprietary  information of the sender,
and is intended only for the person(s) to whom it is addressed. Any use,
distribution, copying or disclosure by any other person  is strictly prohibited.
If
you have  received this message in error,  please notify  the e-mail sender
immediately, and delete the original message without making a copy.

-> END TRANSMISSION <-

_

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.
_
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [UPDATE] New Boot-Loader Menu -- version 1.1

[John Baldwin]

On Tuesday, May 03, 2011 12:31:14 pm Devin Teske wrote:
> 
> On May 3, 2011, at 4:45 AM, John Baldwin wrote:
> 
> > On Monday, May 02, 2011 8:48:31 pm Devin Teske wrote:
> >> This version (1.1) works nearly identically to the standard menu that 
> >> ships with
> >> FreeBSD in that it detects whether ACPI is enabled (truth be told, I 
> >> actually
> >> re-used the "acpienabled?" function verbatim from /boot/beastie.4th by 
> >> Scott
> >> Long and Aleksander Fafula). The ACPI detection of my boot loader (version 
> >> 1.1
> >> or higher) should be identical to the detection of the current boot-loader.
> 
> Ugh. By "current", I meant 8.1-RELEASE (wasn't expecting this stuff to be 
> different in HEAD, which it is).
> 
> 
> > Err, note that the acpienabled stuff is all different in HEAD than in 7/8
> > since acpi.ko no longer exists.  You should use the scheme from HEAD for
> > handling ACPI present vs ACPI enabled/disabled.
> > 
> > -- 
> > John Baldwin
> 
> 
> Ok, I see the new "acpipresent?" word (which replaces the "arch-i386"
> environment-test). Does this imply that we're going to support ACPI on
> non-i386 platforms (or already do)?

amd64 and ia64 have always supported ACPI.  ia64 effectively requires it.
However, "hint.acpi.0.rsdp" is set by biosacpi.c in the i386 loader bits,
so other platforms will not set it, so the arch-i386 test is no longer
needed.
 
> I also see the rewritten "acpienabled?" word. Nice. I'll slurp it in to
> make my ACPI detection the same as HEAD.
> 
> I also performed some backward compatibility tests. Looks like this will be
> backward compatible with 8.1-RELEASE (loader_version == 11). However, the
> code in HEAD appears to not work in 8.0-RELEASE (loader_version == 8).

Hmm, which part does not work in 8.0?  arch-i386 has existed since at least
4.x I thought, and the ACPI bits have been setting hint.acpi.0.rsdp since 7.0
(sys/boot/i386/libi386/biosacpi.c CVS rev 1.12 added it).

-- 
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [UPDATE] New Boot-Loader Menu -- version 1.1

[Devin Teske]

On May 3, 2011, at 4:45 AM, John Baldwin wrote:

> On Monday, May 02, 2011 8:48:31 pm Devin Teske wrote:
>> This version (1.1) works nearly identically to the standard menu that ships 
>> with
>> FreeBSD in that it detects whether ACPI is enabled (truth be told, I actually
>> re-used the "acpienabled?" function verbatim from /boot/beastie.4th by Scott
>> Long and Aleksander Fafula). The ACPI detection of my boot loader (version 
>> 1.1
>> or higher) should be identical to the detection of the current boot-loader.

Ugh. By "current", I meant 8.1-RELEASE (wasn't expecting this stuff to be 
different in HEAD, which it is).


> Err, note that the acpienabled stuff is all different in HEAD than in 7/8
> since acpi.ko no longer exists.  You should use the scheme from HEAD for
> handling ACPI present vs ACPI enabled/disabled.
> 
> -- 
> John Baldwin


Ok, I see the new "acpipresent?" word (which replaces the "arch-i386" 
environment-test). Does this imply that we're going to support ACPI on non-i386 
platforms (or already do)?

I also see the rewritten "acpienabled?" word. Nice. I'll slurp it in to make my 
ACPI detection the same as HEAD.

I also performed some backward compatibility tests. Looks like this will be 
backward compatible with 8.1-RELEASE (loader_version == 11). However, the code 
in HEAD appears to not work in 8.0-RELEASE (loader_version == 8).

I'm thinking about adding the following test-case to the "acpienabled?" word to 
add backward compatibility:

: acpienabled? ( -- flag )
\ BEGIN: Additional code for backward compatibility
s" loader_version" environment? if
11 < if
\ older version of loader(8)
s" acpi_load" getenv
dup -1 = if
drop false exit
then
s" YES" compare-insensitive 0<> if
false exit
then
then
then
\ END: Additional code for backward compatibility
\ BEGIN: Existing code in HEAD
s" hiint.acpi.0.disabled" getenv
dup -1 <> if
s" 0" compare 0<> if
false exit
then
else
drop
then
true
\ END: Existing code in HEAD
;

In-addition, I'm also thinking about adding the following test-case to the new 
"acpipresent?" word to add backward compatibility:

: acpipresent? ( -- flag )
\ BEGIN: Additional code for backward compatibility
s" loader_version" environment? if
11 < if
\ older version of loader(8)
s" arch-i386" environment? if
drop true exit
else
false exit
then
then
then
\ END: Additional code for backward compatibility
\ BEGIN: Existing code in HEAD
s" hint.acpi.0.rsdp" getenv
dup -1 = if
drop false exit
then
2drop
true
\ END: Existing code in HEAD
;

What do you think? I'm actually thinking this would be a good change to 
incorporate HEAD.
-- 
Cheers,
Devin Teske

-> CONTACT INFORMATION <-
Business Solutions Consultant II
FIS - fisglobal.com
510-735-5650 Mobile
510-621-2038 Office
510-621-2020 Office Fax
909-477-4578 Home/Fax
devin.te...@fisglobal.com

-> LEGAL DISCLAIMER <-
This message  contains confidential  and proprietary  information
of the sender,  and is intended only for the person(s) to whom it
is addressed. Any use, distribution, copying or disclosure by any
other person  is strictly prohibited.  If you have  received this
message in error,  please notify  the e-mail sender  immediately,
and delete the original message without making a copy.

-> END TRANSMISSION <-

_

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.
_
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [UPDATE] New Boot-Loader Menu -- version 1.1

[John Baldwin]

On Monday, May 02, 2011 8:48:31 pm Devin Teske wrote:
> This version (1.1) works nearly identically to the standard menu that ships 
> with
> FreeBSD in that it detects whether ACPI is enabled (truth be told, I actually
> re-used the "acpienabled?" function verbatim from /boot/beastie.4th by Scott
> Long and Aleksander Fafula). The ACPI detection of my boot loader (version 1.1
> or higher) should be identical to the detection of the current boot-loader.
> 
> I would be willing to bet that your workstation -- while running the default
> boot loader -- displays "Boot FreeBSD with ACPI enabled" for option #2
> (indicating that ACPI appears to be disabled from your system's perspective).
> 
> As far as I know, the loader does not know that ACPI is compiled into your
> kernel. Rather the ACPI menuitem (both in the default boot-loader menu and in 
> my
> version 1.1) hinges on whether "acpi_load" is defined (and is enabled).
> 
> On a side-note, the same exact code is displaying ACPI as enabled for me
> (running under Parallels 4 on Mac OS X 10.6.7) at boot time. Yet, I do not 
> have
> acpi_load in loader.conf(5), though I do have a kernel with ACPI built-in. My
> guess is that loader(8) is setting load_acpi="YES", which I verify immediately
> after executing loader(8) and the loader.4th start-word (which reads
> loader.conf(5) among other things).

Err, note that the acpienabled stuff is all different in HEAD than in 7/8
since acpi.ko no longer exists.  You should use the scheme from HEAD for
handling ACPI present vs ACPI enabled/disabled.

-- 
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [UPDATE] New Boot-Loader Menu -- version 1.3

[Olivier Smedts]

2011/5/3 Devin Teske :
> Hey all,
> Proud to bring you version 1.3 which completes the followup suggestions made
> by Olivier Smedts (use autoboot_delay instead of loader_menu_timeout and
> change dc_seconds to loader_delay) and a couple other minor
> enhancements/fixes.
> I think that brings everything up to speed with the phenomenal feedback
> provided so far. Really, thank you all very much.

That was fast !

> Get your update
> at http://druidbsd.sf.net/ or http://druidbsd.sourceforge.net/download/loader_menu-1.3.tgz

Installed here, on another computer.

Added to /boot/loader.conf :
loader_delay="0"
loader_color="YES"

Removed :
loader_logo="beastie"

Kept :
autoboot_delay="3"

I'm happy with it. The "stop delay on all keys" feature is great, I
have an habit of using arrow keys to stop or reset delays in boot
loaders because those keys usually don't have a special meaning like
letters or space bar can have (except selecting another entry, in grub
for example).

But still, on this computer I've got "2. ACPI Support: Disabled",
while the old loader offers me to boot with ACPI disabled. ACPI seems
enabled after boot in both cases. I've got this behavior on 2
computers with different hardware, they both use 9-CURRENT (latest and
few days old) amd64, compiled with clang. I'll try to investigate a
little more.

Cheers

-- 
Olivier Smedts                                                 _
                                        ASCII ribbon campaign ( )
e-mail: oliv...@gid0.org        - against HTML email & vCards  X
www: http://www.gid0.org    - against proprietary attachments / \

  "Il y a seulement 10 sortes de gens dans le monde :
  ceux qui comprennent le binaire,
  et ceux qui ne le comprennent pas."
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [UPDATE] New Boot-Loader Menu -- version 1.1

[Olivier Smedts]

2011/5/3 Devin Teske :
>> The previous loader behavior when an unknown key was pressed was to reset
>> the delay to the autoboot_delay value.
>
> I wasn't aware of that functionality (I'd always pressed SPACE to pause the
> timer).
>
> Maybe a dumb question, but why would anybody want to reset the timer? I can't
> think of a single scenario where I'd prefer a timer to be reset on keypress
> opposed to just stopping. I'm of the school of thought that there are only 
> three
> reasonable scenarios where you'd want to abate auto-boot (listed below), all 
> of
> which involve more time than just "another 10 seconds" gained by resetting the
> timer:
>
> 1. Slow readers (of which I am guilty of)
> 2. People that just want to bask in the glory of the boot-loader (also guilty)
> 3. Hackers that want to rewrite rogue(6) in FICL for the boot-loader (work in
> progress?)

It surprised me and this loader booted the system while I didn't want, because :
- I was accustomed of the previous behavior
- I only had a 3 seconds delay to boot (I press a key when I want a
longer delay, to read or find a key)
- I wanted to see the new loader (you can count this as "slow readers")
- I don't have a qwerty keyboard, so finding the right keys for the
loader can take some time

> Is this a serious concern (removing the "reset timer on unknown key"
> functionality)?
>
>> And it also worked with, for examble, the
>> arrow keys. I appreciated it, like I appreciate your "Space to pause" !
>
> Arrow keys are funny. They produce a zero value by the "key" function, so
> detecting them is ... impossible.
>
> However, I was able to correct this behavior. Version 1.2 (just released right
> now) will cancel the timeout on ANY keypress, including keys that produce NULL
> keycodes (such as arrows, navigational keys, command sequences, and special 
> key
> combinations).

OK, I'll test it, now the behavior is more like the previous loader,
or grub. It's ok (for me) not to reset the timer if at least it stops
on all keys !

>> Do you know why this loader displays "ACPI Support: Disabled" on my 9-CURRENT
>> amd64 computer when it really seems to be enabled ? Note acpi.ko is not
> loaded,
>> it's in the GENERIC kernel.
>
> The previous version (1.0) had a hard-coded "set acpi_load=YES" in
> /boot/menu-commands.4th. This has been removed in favor of dynamically 
> detecting
> "acpi_load" at boot time.
>
> This version (1.1) works nearly identically to the standard menu that ships 
> with
> FreeBSD in that it detects whether ACPI is enabled (truth be told, I actually
> re-used the "acpienabled?" function verbatim from /boot/beastie.4th by Scott
> Long and Aleksander Fafula). The ACPI detection of my boot loader (version 1.1
> or higher) should be identical to the detection of the current boot-loader.
>
> I would be willing to bet that your workstation -- while running the default
> boot loader -- displays "Boot FreeBSD with ACPI enabled" for option #2
> (indicating that ACPI appears to be disabled from your system's perspective).

No, it displays "Boot FreeBSD with ACPI disabled". I didn't know this
text was dynamic, are you sure it's not hard-coded ?
I can provide screenshots of both loaders.

> As far as I know, the loader does not know that ACPI is compiled into your
> kernel. Rather the ACPI menuitem (both in the default boot-loader menu and in 
> my
> version 1.1) hinges on whether "acpi_load" is defined (and is enabled).
>
> On a side-note, the same exact code is displaying ACPI as enabled for me
> (running under Parallels 4 on Mac OS X 10.6.7) at boot time. Yet, I do not 
> have
> acpi_load in loader.conf(5), though I do have a kernel with ACPI built-in. My
> guess is that loader(8) is setting load_acpi="YES", which I verify immediately
> after executing loader(8) and the loader.4th start-word (which reads
> loader.conf(5) among other things).
>
>> > loader_menu_timeout="N"
>> >
>> >        Timeout in seconds (N) until the menu aborts, causing the
>> > system to
>> >        autoboot with the displayed options. Default is 10 seconds.
>> > Pressing
>> >        any key during the duration will cancel the timeout.
>>
>> Could you add a compatibility shim for the actual autoboot_delay variable ?
>
> I've decided to simply do-away with loader_menu_timeout and have it simply use
> autoboot_delay. This is effective as of version 1.2 (released today).
>
>> > dc_seconds="N"
>> >
>> >        By default, loader_menu introduces a 2-second delay before
>> > launching
>> >        the menu for improved debugging abilities. This option
>> > customizes the
>> >        duration (setting it to zero disables the delay). However, it
>> > is worth
>> >        noting that pressing ENTER anytime during the delay will
>> > preempt the
>> >        duration, launching the menu immediately upon keypress.
>>
>> For consistency with all the logo_* variables, what would you think of using
>> something like loader_delay instead of dc_seconds ? (and yes, I know,
>> autoboot_dela

[UPDATE] New Boot-Loader Menu -- version 1.3

[Devin Teske]

Hey all,

Proud to bring you version 1.3 which completes the followup suggestions made by 
Olivier Smedts (use autoboot_delay instead of loader_menu_timeout and change 
dc_seconds to loader_delay) and a couple other minor enhancements/fixes.

I think that brings everything up to speed with the phenomenal feedback 
provided so far. Really, thank you all very much.

Get your update at http://druidbsd.sf.net/ or 
http://druidbsd.sourceforge.net/download/loader_menu-1.3.tgz

Here's a dump of the latest pkg-descr (the pertinent parts that have changed 
are highlighted above and one additional paragraph added to the end about 
loader_delay):

loader_menu is a modern boot loader for the FreeBSD Operating System.

The following options can be added to loader.conf(5) to customize the behavior
and/or appearance of the boot menu/process:

autoboot_delay="N"

Timeout in seconds (N) until the menu aborts, causing the system to
autoboot with the displayed options. Default is 10 seconds. Pressing
any key during the duration will cancel the timeout.

You can use values as high as you like, however due to limited screen
real-estate (at a mere 24 rows x 80 columns for compatibility reasons)
the counter will simply display "9 seconds" while counting down
internally. Once the final countdown is upon you, the numbers will
finally start to move. A future version could overcome this limitation.

loader_menu_timeout_x="N"
loader_menu_timeout_y="N"

Column (x) and row (y) placement of the menu timeout count-down text.
Defaults are 4 (x) and 23 (y).

loader_color="YES"

Enables the use of color in the boot menu. Not all devices support the
display of ANSI color codes, and so the default is to not use them.

loader_logo="..."

Selects which FreeBSD logo to display. Valid values are "beastie",
"beastiebw", "fbsdbw", "orb", or "orbbw". An invalid value (such as
"none") will disable the display of any logo. The logo is displayed to
the right of the dynamic menu.

loader_logo_x="N"
loader_logo_y="N"

Column (x) and row (y) placement of FreeBSD" mascot placed to the right
of the dynamic menu. Defaults are 46 (x) and 4 (y).

loader_brand="..."

Selects the BSD brand to display. Valid values are "fbsd" (displays
"FreeBSD") and "dbsd" (displays "DruidBSD"). An invalid value (such as
"none") will disable the display of any brand. The brand is displayed
above the dynamic menu. The default is "fbsd".

loader_brand_x="N"
loader_brand_y="N"

Column (x) and row (y) placement of the brand text ("FreeBSD") placed
above the dynamic menu. Defaults are 2 (x) and 1 (y).

loader_password="..."

Sets a password (up to 16 characters long) that is required to be
entered before the system is allowed to boot. Default is to not ask
for a password if unset or NULL.

loader_version="..."

Overrides the display of the loader's built-in version. Displays the
text at the bottom-right edge of the screen (underneath beastie). The
version text is right-justified when displayed.

The current default is to not display any text. However, as-of
RELENG_9, there may be plans to modify loader(8) to export this
variable for display during the boot process, displaying the version
of boot-loader for trouble-shooting purposes.

loader_version_x="N"
loader_version_y="N"

Column (x) and row (y) placement of the loader's built-in version at
the bottom-right edge of the screen. Defaults are 80 (x) and 24 (y).
The version text is right-justified with the text ending at (x,y).

loader_delay="N"

By default, loader_menu introduces a 2-second delay before launching
the menu for improved debugging abilities. This option customizes the
duration (setting it to zero disables the delay). However, it is worth
noting that pressing ENTER anytime during the delay will preempt the
duration, launching the menu immediately upon keypress.

During this delay, a string of dots is displayed. The user can press
Ctrl-C or Esc on the keyboard to prevent the loading of the dynamic
menu system. After pressing either of these keys, the loader will drop
to the usual autoboot sequence (counting down autoboot_delay seconds
until booting the loaded kernel). During the autoboot sequence, any key
pressed except for ENTER will allow escaping to the loader prompt.



WWW: http://druidbsd.sourceforge.net/

-- 
Cheers,
Devin Teske


-> LEGAL DISCLAIMER <-
This message  contains confidential  and proprietary  information
of the sender,  and is intended only for the person(s) to whom it
is addressed. Any use, distribution, copying or disclosure by any
other person  is strictly prohibited.  If you have  received this
message in error,  please 

RE: [UPDATE] New Boot-Loader Menu -- version 1.1

[Devin Teske]

UPDATE: New version 1.2 released right now.
Get your update at:
http://druidbsd.sourceforge.net/
or
http://druidbsd.sourceforge.net/download/loader_menu-1.2.tgz

Keep reading for details/discussion below.

> -Original Message-
> From: Olivier Smedts [mailto:oliv...@gid0.org]
> Sent: Monday, May 02, 2011 2:25 PM
> To: Devin Teske
> Cc: FreeBSD Hackers; m...@mired.org; m...@freebsd.org;
> me...@freebsd.org; war...@freebsd.org; l...@freebsd.org;
> fred...@freebsd.org; c...@freebsd.org; alexan...@freebsd.org;
> leidin...@freebsd.org; oliv...@freebsd.org; sme...@freebsd.org;
> war...@freebsd.org; bl...@freebsd.org; d...@freebsd.org;
> bar...@freebsd.org; ar...@freebsd.org; belev...@freebsd.org;
> die...@freebsd.org; b...@freebsd.org; ja...@freebsd.org;
> hellent...@freebsd.org; de...@freebsd.org; te...@freebsd.org;
> dam...@freebsd.org; fleur...@freebsd.org; zhi...@freebsd.org;
> y...@freebsd.org; p...@freebsd.org; schenkev...@freebsd.org;
> meh...@freebsd.org; e...@freebsd.org; sanlit...@freebsd.org;
> d...@freebsd.org; robi...@freebsd.org
> Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1
> 
> 2011/5/2 Devin Teske :
> > NOTE: Apologies if this comes through multiple times. I'm having problems
> getting this e-mail to appear on the list.
> >
> > Hi again, fellow hackers,
> >
> > First, I'd like to thank all of you for the input and suggestions that you
provided.
> >
> > Things are moving fast and nimble here. With over 1,000 lines of code
changed
> (in one single 24-hour period), I'd like to announce an update to my advanced
> boot-loader menu. This version (1.1) attempts to address all community
> requests.
> >
> > You can grab the updated code here:
> > http://druidbsd.sourceforge.net/
> >        or
> > http://druidbsd.sourceforge.net/download/loader_menu-1.1.tgz
> 
> Using it right now. Great :)

^_^


> What would you think of using the "bw" variant of a logo when
> loader_color="NO" ?
> Oh forget that, I tried without a loader_logo setting, and it seems to be the
case
> with the default orb. It was only strange with my previous setting of
> loader_logo="beastie", without the new "loader_color"
> setting.

Right. I wanted it to function so that if you explicitly set loader_logo, that
it would override the use of loader_color. If you don't set loader_logo, then
playing with loader_color will automatically switch from orbbw to orb, whereas
if you set it to something like "beastie", you'll get that logo regardless of
what loader_color is set to.


> The previous loader behavior when an unknown key was pressed was to reset
> the delay to the autoboot_delay value.

I wasn't aware of that functionality (I'd always pressed SPACE to pause the
timer).

Maybe a dumb question, but why would anybody want to reset the timer? I can't
think of a single scenario where I'd prefer a timer to be reset on keypress
opposed to just stopping. I'm of the school of thought that there are only three
reasonable scenarios where you'd want to abate auto-boot (listed below), all of
which involve more time than just "another 10 seconds" gained by resetting the
timer:

1. Slow readers (of which I am guilty of)
2. People that just want to bask in the glory of the boot-loader (also guilty)
3. Hackers that want to rewrite rogue(6) in FICL for the boot-loader (work in
progress?)

Is this a serious concern (removing the "reset timer on unknown key"
functionality)?


> And it also worked with, for examble, the
> arrow keys. I appreciated it, like I appreciate your "Space to pause" !
> 

Arrow keys are funny. They produce a zero value by the "key" function, so
detecting them is ... impossible.

However, I was able to correct this behavior. Version 1.2 (just released right
now) will cancel the timeout on ANY keypress, including keys that produce NULL
keycodes (such as arrows, navigational keys, command sequences, and special key
combinations).


> Do you know why this loader displays "ACPI Support: Disabled" on my 9-CURRENT
> amd64 computer when it really seems to be enabled ? Note acpi.ko is not
loaded,
> it's in the GENERIC kernel.
> 

The previous version (1.0) had a hard-coded "set acpi_load=YES" in
/boot/menu-commands.4th. This has been removed in favor of dynamically detecting
"acpi_load" at boot time.

This version (1.1) works nearly identically to the standard menu that ships with
FreeBSD in that it detects whether ACPI is enabled (truth be told, I actually
re-used the "acpienabled?" function verbatim from /boot/beastie.4th by Scott
Long and Aleksander Fafula). The ACPI detection of my boot loader (version 1.1
or 

Re: [UPDATE] New Boot-Loader Menu -- version 1.1

[Olivier Smedts]

2011/5/2 Devin Teske :
> NOTE: Apologies if this comes through multiple times. I'm having problems 
> getting this e-mail to appear on the list.
>
> Hi again, fellow hackers,
>
> First, I'd like to thank all of you for the input and suggestions that you 
> provided.
>
> Things are moving fast and nimble here. With over 1,000 lines of code changed 
> (in one single 24-hour period), I'd like to announce an update to my advanced 
> boot-loader menu. This version (1.1) attempts to address all community 
> requests.
>
> You can grab the updated code here:
> http://druidbsd.sourceforge.net/
>        or
> http://druidbsd.sourceforge.net/download/loader_menu-1.1.tgz

Using it right now. Great :)

What would you think of using the "bw" variant of a logo when
loader_color="NO" ?
Oh forget that, I tried without a loader_logo setting, and it seems to
be the case with the default orb. It was only strange with my previous
setting of loader_logo="beastie", without the new "loader_color"
setting.

The previous loader behavior when an unknown key was pressed was to
reset the delay to the autoboot_delay value. And it also worked with,
for examble, the arrow keys. I appreciated it, like I appreciate your
"Space to pause" !

Do you know why this loader displays "ACPI Support: Disabled" on my
9-CURRENT amd64 computer when it really seems to be enabled ? Note
acpi.ko is not loaded, it's in the GENERIC kernel.

> loader_menu_timeout="N"
>
>        Timeout in seconds (N) until the menu aborts, causing the system to
>        autoboot with the displayed options. Default is 10 seconds. Pressing
>        any key during the duration will cancel the timeout.

Could you add a compatibility shim for the actual autoboot_delay variable ?

> dc_seconds="N"
>
>        By default, loader_menu introduces a 2-second delay before launching
>        the menu for improved debugging abilities. This option customizes the
>        duration (setting it to zero disables the delay). However, it is worth
>        noting that pressing ENTER anytime during the delay will preempt the
>        duration, launching the menu immediately upon keypress.

For consistency with all the logo_* variables, what would you think of
using something like loader_delay instead of dc_seconds ? (and yes, I
know, autoboot_delay doesn't begin with "loader_", but it was there
before ;)

Many thanks !

-- 
Olivier Smedts                                                 _
                                        ASCII ribbon campaign ( )
e-mail: oliv...@gid0.org        - against HTML email & vCards  X
www: http://www.gid0.org    - against proprietary attachments / \

  "Il y a seulement 10 sortes de gens dans le monde :
  ceux qui comprennent le binaire,
  et ceux qui ne le comprennent pas."
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

[UPDATE] New Boot-Loader Menu -- version 1.1

[Devin Teske]

NOTE: Apologies if this comes through multiple times. I'm having problems 
getting this e-mail to appear on the list.

Hi again, fellow hackers,

First, I'd like to thank all of you for the input and suggestions that you 
provided.

Things are moving fast and nimble here. With over 1,000 lines of code changed 
(in one single 24-hour period), I'd like to announce an update to my advanced 
boot-loader menu. This version (1.1) attempts to address all community requests.

You can grab the updated code here:
http://druidbsd.sourceforge.net/
or
http://druidbsd.sourceforge.net/download/loader_menu-1.1.tgz

==

Below is an itemized list of things addressed in this latest release (complete 
with attribution to the person(s) whom made the request):

Mike Meyer: Individual menuitem hotkeys have been implemented. (ENTER = boot, a 
= ACPI, v = verbose, s = single-user, m = safe-mode, esc = escape to loader 
prompt).

Paul Schenkeveld, Damien Fleuriot, Zhihao Yuan, and Warner Losh: Both numbers 
and hotkeys are supported.

Freddie Cash: Customize beastie logo with loader.conf(5) variables (see below 
-- also documented in package description).

Alexander Leidinger: When loader_color is enabled (see loader.conf(5) variables 
below -- also documented in package description), the hotkeys/mnemonics are 
bolded (sorry, underline is currently not implemented correctly in loader(8)). 
When loader_color is disabled (the default), the hotkeys/mnemonics appear in 
[square-brackets] (e.g. [ENTER], [A], [V], [M], [S], and [Esc]). Also, when 
loader_color is enabled, the numerical prefixes are also made bold (when 
loader_color is disabled, the numerical prefixes are displayed normally -- 
without square-brackets).

Olivier SMEDTS: All loader.conf(5) variables that are supported by the current 
loader are now supported, including `loader_logo' and many many more (see 
loader.conf(5) variables below -- also documented in package description).

Warren Block and Doug Barton: With respect to ANSI underline being a more 
standard UI choice for hotkey/mnemonics... sorry, ANSI underline is currently 
not implemented correctly in loader(8) as of RELENG_8 that I've tried. Going 
with ANSI bold when loader_color is enabled and square-brackets by default.

Artem Belevich: The default layout should meet all VT100 requirements (that is 
to explain, that "out of the box" with no additional customizations in 
loader.conf(5), the menu should meet VT100 standards).

Dieter BSD: In the "out of box" configuration (assuming the user doesn't have 
any existing customizations in loader.conf(5)), all of your 
previously-mentioned decrees have been met (no graphics, no color, no 
assumptions, etc. etc.). The only requirements are that you have an 80x24 
screen and a basic keyboard with either letters 1-7 or A-Z+ENTER (or both).

Jason Hellenthal (aka jhell): The ability to display the loader version at the 
bottom-right edge of the screen (right-justified) is enabled. However, 
currently the loader does not export the "loader_version" environment variable, 
and thus nothing will be displayed until then. Though, to test this feature, 
you can simply add a line to loader.conf(5) (see the loader.conf(5) variables 
below -- also documented in the package description).

All: The initial delay introduced before loading the menu can be 
disabled/customized (see loader.conf(5) variables below -- also documented in 
package description).

Mehmet Erol Sanliturk: You can customize the default 10-second menu timeout by 
adding `loader_menu_timeout' to loader.conf(5) (see the loader.conf(5) 
variables below -- also documented in the package description). You had stated 
a desire to increase the timeout to 255. Minor note: due to limited screen 
real-estate, the countdown timer will continue to display "9 seconds" until the 
internal timer gets to a number that is below 9 (however, this should still 
meet your needs of dramatically increasing the timeout delay).

==

Here's the package description (+DESC: attainable via either `tar zxfO 
loader_menu-X.Y.tgz +DESC | less' or `pkg_info -dx loader_menu | less'):

loader_menu is a modern boot loader for the FreeBSD Operating System.

The following options can be added to loader.conf(5) to customize the behavior
and/or appearance of the boot menu/process:

loader_color="YES"

Enables the use of color in the boot menu. Not all devices support the
display of ANSI color codes, and so the default is to not use them.

loader_logo="..."

Selects which FreeBSD logo to display. Valid values are "beastie",
"beastiebw", "fbsdbw", "orb", or "orbbw". An invalid value (such as
"none") will disable the display of any logo. The logo is displayed to
the right of the dynamic menu.

loader_logo_x="N"
loader_logo_y="N"

Column (x) and row (y) placement of FreeBSD" mascot placed to the right
of the dynamic menu. Defaul

Re: [RELEASE] New Boot-Loader Menu

[Devin Teske]

On Apr 30, 2011, at 8:11 PM, Jason Hellenthal wrote:

> 
> Devin,
> 
> 
> On Sat, Apr 30, 2011 at 04:00:47PM -0700, Devin Teske wrote:
>> 
>>> Would be nice: "uname -v" of the kernel it will boot.
>> 
>> That's a bit more technically challenging. I'll have another look at the
>> FICL words available, but I don't recall if there was a way to crawl the
>> object space of the items loaded with ``load'' (looking for the uname). I'm
>> open to suggestions if you had an idea of how to do this in Forth -- else
>> I'd think this would need to be a loader(8) modification.
> 
> How about forgetting a mention of unmae & ... instead look into if we
> can support some sort of bootcode versioning to be displayed on the
> screen. This would serve to be very helpful in the future when for say a
> new version of bootcode for ZFS has to be installed then it would be
> easy for announce@ to simply say "A new version of ZFS has been MFCd and
> requires boot version >= X. To find out your version please see the
> bottom right hand corner of your boot screen."
> 
> I would place a pretty good bet that loader(8) could be modified to
> export some sort of versioning of the bootcode to make this a easier
> stance for the user to gather information before a upgrade.

Piece of cake! If you give me a loader(8) that exports a "version" environment 
variable, I'll give the Forth functionality in mere seconds. It's already been 
developed (but was not packaged).

I have a module named "version.4th" which prints the value of the "version" 
environment variable at the bottom-right of the screen underneath the beastie 
logo.

Since you mention this, I'll add the code to the next package and if/when 
loader(8) ever exports a "version" environment variable, it will just magically 
appear. How's that sound?


> 
> -- 
> 
> Regards, (jhell)
> Jason Hellenthal
> 

-- 
Cheers,
Devin Teske


-> LEGAL DISCLAIMER <-
This message  contains confidential  and proprietary  information
of the sender,  and is intended only for the person(s) to whom it
is addressed. Any use, distribution, copying or disclosure by any
other person  is strictly prohibited.  If you have  received this
message in error,  please notify  the e-mail sender  immediately,
and delete the original message without making a copy.

-> FUN STUFF <-
-BEGIN GEEK CODE BLOCK-
Version 3.12
GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB$ P@$ L$ E-
W+++ N? o? K? w@ O M++$ V- PS+>++ PE@ Y+ PGP-> t(+) 5? X(+) R(-) tv+ b+>++ DI+
D+(++) G++ e> h r+++ z+++
--END GEEK CODE BLOCK--
http://www.geekcode.com/

-> END TRANSMISSION <-

_

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.
_
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RELEASE] New Boot-Loader Menu

[Devin Teske]

On Apr 30, 2011, at 6:10 PM, Dieter BSD wrote:

>> Already on the to-do list is to support ``loader_logo=...'' in
>> /boot/loader.conf
> 
> Including an option for no logo? (For consoles that are slow and/or
> small, and for people that just don't like the logos.)

The current behavior -- with what's in CVS today -- is to draw a logo for all 
values of "loader_logo" except for "none".

My menu differs slightly, improving functionality by defaulting to not draw any 
logo for values we don't understand. Therefore "none" would have the desired 
effect (but so will "NO", "blank", "johnnycat", "billjoy", or even "" -- all 
produce a menu with no logo). NOTE: If NULL, we don't display the logo, however 
if unset, we'll default to displaying the chosen/sensible default (going for 
`orbbw' to comply with the aforementioned compatibility decrees -- of which I 
fully agree with). This is to facilitate the loader.conf(5) override ability.

Currently, you'd make the change by altering the ``set logo="orb"'' line in 
/etc/menu.rc (line 10). In the next release, I plan to change the environment 
variable from "logo" to "loader_logo" for backward compatibility (allowing 
loader.conf(5) override as previously mentioned).


> 
>>> Putting brackets around letters (and numbers) sounds good.
>>> If there is room, perhaps add a message explaining that
>>> the user should enter one of the choices in brackets.
>> 
>> I think I'm going to have to play with this and see what we come up with. I
>> don't want to make it too "busy" if you know what I mean. That's with
>> respect to the brackets. As for adding a messages... things are a bit tight
>> and again, I'm afraid of making it too cluttered. I'll post some screenshots
>> of some mock-ups tomorrow, incorporating the various requests.
>> 
>>> A help option would be useful, giving a reminder of what
>>> things like ACPI and APIC stand for, what "safe" mode does, etc.
>> 
>> This is not altogether infeasible. Since this menu (unlike the current one)
>> has the ability to be wiped from screen and then recalled completely in the
>> original state is was left in ... implementing an F1 feature that reads text
>> from a file would be very do-able.
> 
> If there is a help option that the user can figure out how to execute,
> the explaination about brackets (if you go that route), entering numbers,
> letters, and such could be included in the help screen(s) instead of the
> main menu page.

One of the decrees was that we shouldn't assume that there are function keys. I 
think that's a fair decree, so that puts me in a quandry with the "Press F1 for 
Help" model of presentation. Although convenient programmatically, it could 
potentially leave users without function-keys without an ability to read the 
carefully prepared messages awaiting their keypress.

There's really only room for one or two more menu items. Perhaps we could 
introduce a new menuitem after the reboot item. A menuitem whose number is 
perhaps not a number, but instead the question-mark. The text for which could 
be "[H]elp" (keeping to the recent bracketed concept -- which could 
conceptually switch to underline if loader_color is set).


> 
>>> Would be nice: a fix for having to lean on a key autorepeating
>>> for a couple seconds.
>> 
>> Could you explain? I don't follow.
> 
> On my Tyan Tomcat k8e 2865, just entering the number rarely if
> ever works. I have to either repeatedly bang away at the key or
> hold it down, letting the RS-232 terminal do the autorepeat thing,
> while hoping that it notices before the timer runs out.

Is that with the current code that's in CVS? I'd love for you to try my code on 
that hardware. One of the things that I worked on in the very beginning was the 
responsiveness.
-- 
Cheers,
Devin Teske


-> LEGAL DISCLAIMER <-
This message  contains confidential  and proprietary  information
of the sender,  and is intended only for the person(s) to whom it
is addressed. Any use, distribution, copying or disclosure by any
other person  is strictly prohibited.  If you have  received this
message in error,  please notify  the e-mail sender  immediately,
and delete the original message without making a copy.

-> FUN STUFF <-
-BEGIN GEEK CODE BLOCK-
Version 3.12
GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB$ P@$ L$ E-
W+++ N? o? K? w@ O M++$ V- PS+>++ PE@ Y+ PGP-> t(+) 5? X(+) R(-) tv+ b+>++ DI+
D+(++) G++ e> h r+++ z+++
--END GEEK CODE BLOCK--
http://www.geekcode.com/

-> END TRANSMISSION <-

_

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.
_
_

Re: [RELEASE] New Boot-Loader Menu

[Jason Hellenthal]

Devin,


On Sat, Apr 30, 2011 at 04:00:47PM -0700, Devin Teske wrote:
>
>> Would be nice: "uname -v" of the kernel it will boot.
>
>That's a bit more technically challenging. I'll have another look at the
>FICL words available, but I don't recall if there was a way to crawl the
>object space of the items loaded with ``load'' (looking for the uname). I'm
>open to suggestions if you had an idea of how to do this in Forth -- else
>I'd think this would need to be a loader(8) modification.

How about forgetting a mention of unmae & ... instead look into if we
can support some sort of bootcode versioning to be displayed on the
screen. This would serve to be very helpful in the future when for say a
new version of bootcode for ZFS has to be installed then it would be
easy for announce@ to simply say "A new version of ZFS has been MFCd and
requires boot version >= X. To find out your version please see the
bottom right hand corner of your boot screen."

I would place a pretty good bet that loader(8) could be modified to
export some sort of versioning of the bootcode to make this a easier
stance for the user to gather information before a upgrade.

-- 

 Regards, (jhell)
 Jason Hellenthal



pgpSxMzRr5ZWy.pgp
Description: PGP signature

Re: [RELEASE] New Boot-Loader Menu

[Dieter BSD]

> Already on the to-do list is to support ``loader_logo=...'' in
> /boot/loader.conf

Including an option for no logo? (For consoles that are slow and/or
small, and for people that just don't like the logos.)

>> Putting brackets around letters (and numbers) sounds good.
>> If there is room, perhaps add a message explaining that
>> the user should enter one of the choices in brackets.
>
> I think I'm going to have to play with this and see what we come up with. I
> don't want to make it too "busy" if you know what I mean. That's with
> respect to the brackets. As for adding a messages... things are a bit tight
> and again, I'm afraid of making it too cluttered. I'll post some screenshots
> of some mock-ups tomorrow, incorporating the various requests.
>
>> A help option would be useful, giving a reminder of what
>> things like ACPI and APIC stand for, what "safe" mode does, etc.
>
> This is not altogether infeasible. Since this menu (unlike the current one)
> has the ability to be wiped from screen and then recalled completely in the
> original state is was left in ... implementing an F1 feature that reads text
> from a file would be very do-able.

If there is a help option that the user can figure out how to execute,
the explaination about brackets (if you go that route), entering numbers,
letters, and such could be included in the help screen(s) instead of the
main menu page.

>> Would be nice: a fix for having to lean on a key autorepeating
>> for a couple seconds.
>
> Could you explain? I don't follow.

On my Tyan Tomcat k8e 2865, just entering the number rarely if
ever works. I have to either repeatedly bang away at the key or
hold it down, letting the RS-232 terminal do the autorepeat thing,
while hoping that it notices before the timer runs out.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: [RELEASE] New Boot-Loader Menu

[Devin Teske]

> -Original Message-
> From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-
> hack...@freebsd.org] On Behalf Of Dieter BSD
> Sent: Saturday, April 30, 2011 12:28 PM
> To: freebsd-hackers@freebsd.org
> Subject: Re: [RELEASE] New Boot-Loader Menu
> 
> [ attempt #2 - grumble - sorry about the blank message, hope it
> works this time - grumble- ]
> 
> > I hope that works for serial console.  VT100 may be a reasonable
> > default in that case, but it would be good to make sure that menu
> > works even on a dumb terminal. Perhaps we should put 'key' letter
> > in brackets then?
> 
> This needs to work, correctly, everywhere.  This needs to be easy to
> understand by a stressed out user whose machine is having problems.
> 
> Therefore:
> 
> Thou shalt not assume graphics.
> Thou shalt not assume color.
> Thou shalt not assume VT100 or any specific terminal.
> Thou shalt not assume ability to display bold.
> Thou shalt not assume ability to underline text.
> Thou shalt not assume availability of multiple fonts.
> Thou shalt not assume more than 24x80 chars.
> Thou shalt not assume scrollback.
> Thou shalt not assume fancy cursor movements.
> Thou shalt not assume presence of function keys.
> Thou shalt not assume presence of arrow keys.
> Thou shalt not assume a fast interface.
> Thou shalt not assume the three-finger-salute works.
> 

I agree with all those decrees.

I'll make the next version will meet all those requirements in its "out of
the box" configuration.

If users want to make it colorized, I'll provide a knob that can be added to
loader.conf(5) (how about ``loader_color=1'' ??).

Already on the to-do list is to support ``loader_logo=...'' in
/boot/loader.conf


> Putting brackets around letters (and numbers) sounds good.
> If there is room, perhaps add a message explaining that
> the user should enter one of the choices in brackets.
> 

I think I'm going to have to play with this and see what we come up with. I
don't want to make it too "busy" if you know what I mean. That's with
respect to the brackets. As for adding a messages... things are a bit tight
and again, I'm afraid of making it too cluttered. I'll post some screenshots
of some mock-ups tomorrow, incorporating the various requests.


> A help option would be useful, giving a reminder of what
> things like ACPI and APIC stand for, what "safe" mode does, etc.
> 

This is not altogether infeasible. Since this menu (unlike the current one)
has the ability to be wiped from screen and then recalled completely in the
original state is was left in ... implementing an F1 feature that reads text
from a file would be very do-able.

I was at one time experimenting with reading a "version.inf" file from disk
to be displayed at the bottom-right of the screen (under beastie logo) ... a
way of indicating the version of either loader, OS, both, or more (could be
auto-generated as part of release(7) for each/every release).


> Would be nice: "uname -v" of the kernel it will boot.
> 

That's a bit more technically challenging. I'll have another look at the
FICL words available, but I don't recall if there was a way to crawl the
object space of the items loaded with ``load'' (looking for the uname). I'm
open to suggestions if you had an idea of how to do this in Forth -- else
I'd think this would need to be a loader(8) modification.

> Would be nice: a user friendly way to boot from a different
> disk/partition/kernel.  Without the user having to know the
> mapping between what the firmware calls disks and what FreeBSD
> calls disks.  And without writing anything to disk.
> 

That's also a bit technically challenging in Forth, I think. Open to
suggestions, but again would likely be best implemented as a change to
loader(8), no?


> Would be nice: a fix for having to lean on a key autorepeating
> for a couple seconds.
> 

Could you explain? I don't follow.
-- 
Devin


> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

_

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.
_
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RELEASE] New Boot-Loader Menu

[Dieter BSD]

[ attempt #2 - grumble - sorry about the blank message, hope it
works this time - grumble- ]

> I hope that works for serial console.  VT100 may be a reasonable
> default in that case, but it would be good to make sure that menu
> works even on a dumb terminal. Perhaps we should put 'key' letter
> in brackets then?

This needs to work, correctly, everywhere.  This needs to be easy to
understand by a stressed out user whose machine is having problems.

Therefore:

Thou shalt not assume graphics.
Thou shalt not assume color.
Thou shalt not assume VT100 or any specific terminal.
Thou shalt not assume ability to display bold.
Thou shalt not assume ability to underline text.
Thou shalt not assume availability of multiple fonts.
Thou shalt not assume more than 24x80 chars.
Thou shalt not assume scrollback.
Thou shalt not assume fancy cursor movements.
Thou shalt not assume presence of function keys.
Thou shalt not assume presence of arrow keys.
Thou shalt not assume a fast interface.
Thou shalt not assume the three-finger-salute works.

Putting brackets around letters (and numbers) sounds good.
If there is room, perhaps add a message explaining that
the user should enter one of the choices in brackets.

A help option would be useful, giving a reminder of what
things like ACPI and APIC stand for, what "safe" mode does, etc.

Would be nice: "uname -v" of the kernel it will boot.

Would be nice: a user friendly way to boot from a different
disk/partition/kernel.  Without the user having to know the
mapping between what the firmware calls disks and what FreeBSD
calls disks.  And without writing anything to disk.

Would be nice: a fix for having to lean on a key autorepeating
for a couple seconds.

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RELEASE] New Boot-Loader Menu

[Dieter BSD]

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RELEASE] New Boot-Loader Menu

[Alexander Leidinger]

On Fri, 29 Apr 2011 16:55:12 -0700 "Devin Teske" 
wrote:

> > -Original Message-
> > From: Alexander Leidinger [mailto:alexan...@leidinger.net]
> > Sent: Friday, April 29, 2011 1:34 PM
> > To: Devin Teske
> > Cc: 'Mike Meyer'; 'FreeBSD Hackers'
> > Subject: Re: [RELEASE] New Boot-Loader Menu
> > 
> > On Fri, 29 Apr 2011 12:02:03 -0700 "Devin Teske" 
> > wrote:
> > 
> > > I was thinking that what we ought to do is support *both* numbers
> > > *and* letters.
> > 
> > Sounds good to me.
> > 
> > > I envision the menuitem numbers remaining unchanged (1-7),
> > > allowing those familiar with the numbers to use them.
> > >
> > > However, as for the letters, I'm thinking that we *BOLD* the
> > > mnemonic in the menuitem. For example (showing bolded items
> > > between asterisks):
> > >
> > > 1. Boot *[ENTER]*
> > > 2. *A*CPI Support: Enabled
> > > 3. Boot Safe Mode: NO
> > > 4. Boot *S*ingle User: NO
> > > 5. Boot *V*erbose: NO
> > > 6. *Esc*ape to loader prompt
> > > 7. *R*eboot
> > >
> > > This should indicate to the user, for example if they see that
> > > the "V" in "Verbose" is bolded, that they can press that key to
> > > activate that menuitem.
> > 
> 
> Your below points are all valid arguments. However, I think they are
> a bit reaching.
> 
> The types of people that know what it means to boot into Single-User
> and/or Verbose mode would not be prone to thinking in those ways.

Maybe not single user, but maybe verbose.

For me the first question is not how to improve this, my first question
is if we need to improve this.

> I'm still leaning toward just making the "V" in "Verbose" and "S" in
> "Single User" bolded.

Your initial proposal about the characters looked fine for me. Only
making those two in bold looks looks like a step backwards to me.

Bye,
Alexander.

-- 
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RELEASE] New Boot-Loader Menu

[Artem Belevich]

On Fri, Apr 29, 2011 at 8:37 PM, Doug Barton  wrote:
> On 04/29/2011 20:34, Warren Block wrote:
>>
>> On Fri, 29 Apr 2011, Devin Teske wrote:
>>
>>> I'm still leaning toward just making the "V" in "Verbose" and "S" in
>>> "Single
>>> User" bolded.
>>
>> Why not just underline hotkey characters? That's already a well-known
>> standard in lots of places.
>
> Agreed, that's a much more standard UI.

I hope that works for serial console.  VT100 may be a reasonable
default in that case, but it would be good to make sure that menu
works even on a dumb terminal. Perhaps we should put 'key' letter in
brackets then?

--Artem
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RELEASE] New Boot-Loader Menu

[Doug Barton]

On 04/29/2011 20:34, Warren Block wrote:

On Fri, 29 Apr 2011, Devin Teske wrote:


I'm still leaning toward just making the "V" in "Verbose" and "S" in
"Single
User" bolded.


Why not just underline hotkey characters? That's already a well-known
standard in lots of places.


Agreed, that's a much more standard UI.

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: [RELEASE] New Boot-Loader Menu

[Warren Block]

On Fri, 29 Apr 2011, Devin Teske wrote:


I'm still leaning toward just making the "V" in "Verbose" and "S" in "Single
User" bolded.


Why not just underline hotkey characters?  That's already a well-known 
standard in lots of places.

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RELEASE] New Boot-Loader Menu

[Alexander Leidinger]

On Fri, 29 Apr 2011 12:02:03 -0700 "Devin Teske" 
wrote:

> I was thinking that what we ought to do is support *both* numbers
> *and* letters.

Sounds good to me.

> I envision the menuitem numbers remaining unchanged (1-7), allowing
> those familiar with the numbers to use them.
> 
> However, as for the letters, I'm thinking that we *BOLD* the mnemonic
> in the menuitem. For example (showing bolded items between asterisks):
> 
> 1. Boot *[ENTER]*
> 2. *A*CPI Support: Enabled
> 3. Boot Safe Mode: NO
> 4. Boot *S*ingle User: NO
> 5. Boot *V*erbose: NO
> 6. *Esc*ape to loader prompt
> 7. *R*eboot
> 
> This should indicate to the user, for example if they see that the
> "V" in "Verbose" is bolded, that they can press that key to activate
> that menuitem.

Presented like this a naive first interpretion could be that the
letters have to be entered as upper-case. I do not think someone wants
to press shift there...

Having the characters in bold but the numbers not could also let
someone think that only the characters matter.

Having a text which tells that the numbers and lower-case characters
work for chosing something, may be a solution here. Another solution is
maybe
 1/[ENTER]. Boot
 2/a. ACPI Support...
 ...
but I have to admit that the second solution is ugly.
A third solution could be to have the numbers and the characters in
bold.

Bye,
Alexander.

-- 
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: [RELEASE] New Boot-Loader Menu

[Devin Teske]

> -Original Message-
> From: Olivier SMEDTS [mailto:oliv...@gid0.org]
> Sent: Friday, April 29, 2011 4:09 PM
> To: Devin Teske
> Cc: Freddie Cash; FreeBSD Hackers
> Subject: Re: [RELEASE] New Boot-Loader Menu
> 
> Le 29 avr. 2011 à 21:17, Devin Teske  a écrit :
> 
> >> -Original Message-
> >> From: Freddie Cash [mailto:fjwc...@gmail.com]
> >> Sent: Friday, April 29, 2011 11:20 AM
> >> To: Devin Teske
> >> Cc: FreeBSD Hackers
> >> Subject: Re: [RELEASE] New Boot-Loader Menu
> >>
> >> Very nice and functional, without adding a lot of extra verbosity or
> >> steps.  I really appreciated the clean install via binary package.
> >> Well done.
> >>
> >> Only question I have is whether it's possible to use the Beastie
> >> ASCII image instead of the pointy-eared blob?  The beastie.4th file
> >> is still present under /boot, but I don't know how to hook it into the new
> menu.
> >
> > Glad you asked. This couldn't be easier.
> >
> > Open up `/boot/menu.rc' and look for the following lines (LINE 9-10):
> >
> >\ Customizations
> >set logo="orb"
> >
> > Feel free to play with any of the following drop-in replacements:
> >
> >set logo="beastie"
> >set logo="beastiebw"
> >set logo="fbsdbw"
> >set logo="orb"
> >set logo="orbbw"
> 
> Would it be possible to support the curent loader settings present in
> /boot/loader.conf ? I've got something like :
> loader_logo="beastie"
> autoboot_delay="0"
> 

Yeah, that's definitely possible. The new code already supports
/boot/loader.conf, however I don't support loader_logo in that way (you'd have
to use "logo=" instead of "loader_logo=" and you'd have to remove the "set
logo=" line from /boot/menu.rc).

I'll have to make the following modifications in the next version so that you
can use loader_logo from /boot/loader.conf:

1. Change the default logo in /boot/beastie.4th from "beastie" to "orb"
2. Change /boot/menu.rc to remove the line: set logo="orb"
3. Change /boot/beastie.4th to read the "loader_logo" environment variable
instead of "logo"


> And while the pre-menu delay of 2 seconds is great, is it possible to turn it
off or
> adjust it ?
>

Right now, if you want to disable the 2 second delay, open up /boot/loader.rc
and change the following line:

set dc_seconds=2

to:

set dc_seconds=0

In the next release, I'll rewrite it so that you add something to
/boot/loader.conf to disable the delay.
-- 
Devin


> Thanks !
> 
> > Simply deleting the line or comment it out (by adding "\ " --
backslash-space --
> to the beginning of the line) is equivalent to setting logo to "beastie".
Here's a
> short explanation of each value:
> >
> >NAMEDESCRIPTION
> >beastieColor ``Helper Daemon'' mascot (19 rows x 34 columns)
> >beastiebwB/W ``Helper Daemon'' mascot (19 rows x 34 columns)
> >fbsdbw"FreeBSD" logo in B/W (13 rows x 21 columns)
> >orbColor ``Orb'' mascot (15 rows x 30 columns)
> >orbbwB/W ``Orb'' mascot (15 rows x 30 columns)
> >
> > I'm not sure what you meant by "Beastie ASCII" image, but I think you're
either
> looking for "beastie" or "fbsdbw".
> >
> > You should have to, but if you need to, you can add:
> >
> >set logoX=X
> >set logoY=Y
> >
> > to force the row/column placement of beastie.
> > --
> > Devin
> >
> >>
> >> --
> >> Freddie Cash
> >> fjwc...@gmail.com
> >
> > _
> >
> > 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.
> > _
> > ___
> > freebsd-hackers@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

_

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.
_
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: [RELEASE] New Boot-Loader Menu

[Devin Teske]

> -Original Message-
> From: Alexander Leidinger [mailto:alexan...@leidinger.net]
> Sent: Friday, April 29, 2011 1:34 PM
> To: Devin Teske
> Cc: 'Mike Meyer'; 'FreeBSD Hackers'
> Subject: Re: [RELEASE] New Boot-Loader Menu
> 
> On Fri, 29 Apr 2011 12:02:03 -0700 "Devin Teske" 
> wrote:
> 
> > I was thinking that what we ought to do is support *both* numbers
> > *and* letters.
> 
> Sounds good to me.
> 
> > I envision the menuitem numbers remaining unchanged (1-7), allowing
> > those familiar with the numbers to use them.
> >
> > However, as for the letters, I'm thinking that we *BOLD* the mnemonic
> > in the menuitem. For example (showing bolded items between asterisks):
> >
> > 1. Boot *[ENTER]*
> > 2. *A*CPI Support: Enabled
> > 3. Boot Safe Mode: NO
> > 4. Boot *S*ingle User: NO
> > 5. Boot *V*erbose: NO
> > 6. *Esc*ape to loader prompt
> > 7. *R*eboot
> >
> > This should indicate to the user, for example if they see that the "V"
> > in "Verbose" is bolded, that they can press that key to activate that
> > menuitem.
> 

Your below points are all valid arguments. However, I think they are a bit
reaching.

The types of people that know what it means to boot into Single-User and/or
Verbose mode would not be prone to thinking in those ways. And, even if they
were, let's look at the consequences for each:

> Presented like this a naive first interpretion could be that the letters have
to be
> entered as upper-case. I do not think someone wants to press shift there...
>

Scenario:

Naïve User presses Shift-V. Nothing happens. They then press "v" ... the menu
toggles to "YES". They press ENTER. Success -- the naïve user has managed to
boot with the desired options.


> Having the characters in bold but the numbers not could also let someone think
> that only the characters matter.
> 

Scenario:

Naïve user thinks that only the letters matter, and the only bold items on the
menu are "[ENTER]", "S", and "V". Naïve user is left wondering how to activate
menuitems 2, 3, 6, and 7 for which there are no bolded letters. Naïve user never
figures out that the numbers are usable and eventually presses ENTER. The
machine boots.

Ok... you got me on this one ... this hypothetical [extremely] naïve user may
not figure out how to use options 2, 3, 6, and 7, and thus cannot disable ACPI,
cannot boot in Safe Mode (disabling both ACPI and APIC, etc.), nor escape to the
loader prompt, nor reboot (assuming they don't know how the three-finger-solute
or where the power button is).

My concession to this user would be to bold the numbers to the left of each
menuitem. The user would have to be beyond naïveté if they couldn't figure it
out with bold numbers, IMHO.


> Having a text which tells that the numbers and lower-case characters work for
> chosing something, may be a solution here. Another solution is maybe
> 1/[ENTER]. Boot  2/a. ACPI Support...
>  ...
> but I have to admit that the second solution is ugly.
> A third solution could be to have the numbers and the characters in bold.
> 

Yeah, that's no good. Too ugly.

I'm still leaning toward just making the "V" in "Verbose" and "S" in "Single
User" bolded.
-- 
Devin


> Bye,
> Alexander.
> 
> --
> http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
> http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137

_

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.
_
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RELEASE] New Boot-Loader Menu

[Olivier SMEDTS]

Le 29 avr. 2011 à 21:17, Devin Teske  a écrit :

>> -Original Message-
>> From: Freddie Cash [mailto:fjwc...@gmail.com]
>> Sent: Friday, April 29, 2011 11:20 AM
>> To: Devin Teske
>> Cc: FreeBSD Hackers
>> Subject: Re: [RELEASE] New Boot-Loader Menu
>>
>> Very nice and functional, without adding a lot of extra verbosity or steps.  
>> I really
>> appreciated the clean install via binary package.
>> Well done.
>>
>> Only question I have is whether it's possible to use the Beastie ASCII image
>> instead of the pointy-eared blob?  The beastie.4th file is still present 
>> under /boot,
>> but I don't know how to hook it into the new menu.
>
> Glad you asked. This couldn't be easier.
>
> Open up `/boot/menu.rc' and look for the following lines (LINE 9-10):
>
>\ Customizations
>set logo="orb"
>
> Feel free to play with any of the following drop-in replacements:
>
>set logo="beastie"
>set logo="beastiebw"
>set logo="fbsdbw"
>set logo="orb"
>set logo="orbbw"

Would it be possible to support the curent loader settings present in
/boot/loader.conf ? I've got something like :
loader_logo="beastie"
autoboot_delay="0"

And while the pre-menu delay of 2 seconds is great, is it possible to
turn it off or adjust it ?

Thanks !

> Simply deleting the line or comment it out (by adding "\ " -- backslash-space 
> -- to the beginning of the line) is equivalent to setting logo to "beastie". 
> Here's a short explanation of each value:
>
>NAMEDESCRIPTION
>beastieColor ``Helper Daemon'' mascot (19 rows x 34 columns)
>beastiebwB/W ``Helper Daemon'' mascot (19 rows x 34 columns)
>fbsdbw"FreeBSD" logo in B/W (13 rows x 21 columns)
>orbColor ``Orb'' mascot (15 rows x 30 columns)
>orbbwB/W ``Orb'' mascot (15 rows x 30 columns)
>
> I'm not sure what you meant by "Beastie ASCII" image, but I think you're 
> either looking for "beastie" or "fbsdbw".
>
> You should have to, but if you need to, you can add:
>
>set logoX=X
>set logoY=Y
>
> to force the row/column placement of beastie.
> --
> Devin
>
>>
>> --
>> Freddie Cash
>> fjwc...@gmail.com
>
> _
>
> 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.
> _
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: [RELEASE] New Boot-Loader Menu

[Devin Teske]

> -Original Message-
> From: Mike Meyer [mailto:m...@mired.org]
> Sent: Friday, April 29, 2011 12:24 PM
> To: Devin Teske
> Cc: 'FreeBSD Hackers'
> Subject: Re: [RELEASE] New Boot-Loader Menu
> 
> On Fri, 29 Apr 2011 12:02:03 -0700
> "Devin Teske"  wrote:
> > > -Original Message-
> > > From: Mike Meyer [mailto:m...@mired.org] I'd like to revisit the
> > > numbers vs. letters for menu options. IIRC (and I may
> > not),
> > > an earlier version used letters for the menu options, and people
> > > objected to
> > that
> > > change.
> >
> > Looking at the CVS history of the Forth code that renders the menu,
> > I'm
> > noticing:
> >
> > If there was an earlier version of the menu that used letters, I'm not
> > seeing it in CVS.
> 
> I was referring to your code, not the historical FreeBSD code. Didn't you
originally
> propose using letters, not numbers, to toggle the boot options? If not, then
> possibly I'm remembering another proposal.

You're recalling a response to the thread that I started on March 28th, 2011
(last month):
THREAD-HEAD:
http://lists.freebsd.org/pipermail/freebsd-hackers/2011-March/034824.html

The "letters not numbers" post that you're recalling was by Paul S. (below):
http://lists.freebsd.org/pipermail/freebsd-hackers/2011-March/034830.html

Although Paul makes a point that the letters would be helpful, his complaint
about the numbers being changed is a red-herring (he saw the unreleased mock-up
image of my boot-loader -- in the thread-head URL above -- presenting different
numbers and complained that if the numbers change that sysadmins would be
confused). However, the reality is that [a] the final release indeed matches the
numbers with the existing boot loader and [b] the numbers have not changed in 7
years).

Paul, ... supporting evidence to show that the numbers (1-7) have never changed
since their initial commit to CVS on May 30th, 2003 (see the "beastie-menu"
forth word in version 1.1 of beastie.4th circa RELENG_5_0):
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/boot/forth/beastie.4th

The case is merely that Paul would like to see this additional feature added
(letters as mnemonics). I couldn't find any claims that any previous version
(either of my code or official FreeBSD code) ever supported it in the past.

So, I think that the grand-total comes to 5 people now that have requested
hot-keys for the single-user and verbose menu items:

Paul S. (msg #034830)
Zhihao Y. (msg #034831)
Damien F. (msg #034841)
Yourself (Mike M.) (msg #035192 & msg #035197)
and Myself (Devin T. msg #035195)

Let's see if we can't get that list a little higher.

Keep in-mind, the proposal (at least for right now) is to have me extend my code
to bold the "S" in "Single User", bold the "V" in "Verbose", and accept the S/V
key as toggles for these features, all the while maintaining the current number
scheme.

NOTE: I'm going to wait a couple weeks before starting on this, as I've
currently got a couple of other companies evaluating the boot loader in its
current form and would like their feedback before moving forward on the next
revision.

> 
> > > In particular, there was a study done around '80 (I tried to find it
> > > but
> > couldn't; I
> > > know of someone who can probably provide a reference if someone
> > > really wants
> > > it) that showed that menu selection with letters assigned
> > > mnemonically are easiest for users to memorize.
> >
> > I can believe that quite easily. However, currently the boot menu does
> > not support such letters. I think this new loader menu is the perfect
> > place to implement them.
> 
> This seemed like a good time to change it if we were going to to me.

I couldn't agree more.
-- 
Devin


> 
> > On another note, I have one other change that I'd like to get in... I
> > noticed that (in CVS) the menu currently blanks-out option #2 if
> > booting on a system where ACPI is disabled or unavailable. In my boot
> > loader, I'd like to display "ACPI Support: N/A" rather than simply blanking
out
> the menu item.
> 
> That would certainly make the numbers make more sense.
> 
>  Thanks,
>   --
> Mike Meyer 
>   http://www.mired.org/consulting.html
> Independent Software developer/SCM consultant, email for more information.
> 
> O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

_

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; (

Re: [RELEASE] New Boot-Loader Menu

[Mike Meyer]

On Fri, 29 Apr 2011 12:02:03 -0700
"Devin Teske"  wrote:
> > -Original Message-
> > From: Mike Meyer [mailto:m...@mired.org]
> > I'd like to revisit the numbers vs. letters for menu options. IIRC (and I 
> > may
> not),
> > an earlier version used letters for the menu options, and people objected to
> that
> > change.
> 
> Looking at the CVS history of the Forth code that renders the menu, I'm
> noticing:
> 
> If there was an earlier version of the menu that used letters, I'm not seeing 
> it
> in CVS.

I was referring to your code, not the historical FreeBSD code. Didn't
you originally propose using letters, not numbers, to toggle the boot
options? If not, then possibly I'm remembering another proposal.

> > In particular, there was a study done around '80 (I tried to find it but
> couldn't; I
> > know of someone who can probably provide a reference if someone really wants
> > it) that showed that menu selection with letters assigned mnemonically are
> > easiest for users to memorize.
> 
> I can believe that quite easily. However, currently the boot menu does not
> support such letters. I think this new loader menu is the perfect place to
> implement them.

This seemed like a good time to change it if we were going to to me.

> On another note, I have one other change that I'd like to get in... I noticed
> that (in CVS) the menu currently blanks-out option #2 if booting on a system
> where ACPI is disabled or unavailable. In my boot loader, I'd like to display
> "ACPI Support: N/A" rather than simply blanking out the menu item.

That would certainly make the numbers make more sense.

 Thanks,
  http://www.mired.org/consulting.html
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: [RELEASE] New Boot-Loader Menu

[Devin Teske]

> -Original Message-
> From: Freddie Cash [mailto:fjwc...@gmail.com]
> Sent: Friday, April 29, 2011 11:20 AM
> To: Devin Teske
> Cc: FreeBSD Hackers
> Subject: Re: [RELEASE] New Boot-Loader Menu
> 
> Very nice and functional, without adding a lot of extra verbosity or steps.  
> I really
> appreciated the clean install via binary package.
> Well done.
> 
> Only question I have is whether it's possible to use the Beastie ASCII image
> instead of the pointy-eared blob?  The beastie.4th file is still present 
> under /boot,
> but I don't know how to hook it into the new menu.

Glad you asked. This couldn't be easier.

Open up `/boot/menu.rc' and look for the following lines (LINE 9-10):

\ Customizations
set logo="orb"

Feel free to play with any of the following drop-in replacements:

set logo="beastie"
set logo="beastiebw"
set logo="fbsdbw"
set logo="orb"
set logo="orbbw"

Simply deleting the line or comment it out (by adding "\ " -- backslash-space 
-- to the beginning of the line) is equivalent to setting logo to "beastie". 
Here's a short explanation of each value:

NAMEDESCRIPTION
beastie Color ``Helper Daemon'' mascot (19 rows x 34 columns)
beastiebw   B/W ``Helper Daemon'' mascot (19 rows x 34 columns)
fbsdbw  "FreeBSD" logo in B/W (13 rows x 21 columns)
orb Color ``Orb'' mascot (15 rows x 30 columns)
orbbw   B/W ``Orb'' mascot (15 rows x 30 columns)

I'm not sure what you meant by "Beastie ASCII" image, but I think you're either 
looking for "beastie" or "fbsdbw".

You should have to, but if you need to, you can add:

set logoX=X
set logoY=Y

to force the row/column placement of beastie.
-- 
Devin

> 
> --
> Freddie Cash
> fjwc...@gmail.com

_

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.
_
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: [RELEASE] New Boot-Loader Menu

[Devin Teske]

> -Original Message-
> From: Mike Meyer [mailto:m...@mired.org]
> Sent: Friday, April 29, 2011 10:08 AM
> To: Devin Teske
> Cc: FreeBSD Hackers
> Subject: Re: [RELEASE] New Boot-Loader Menu
> 
> On Sun, 24 Apr 2011 18:53:11 -0700
> Devin Teske  wrote:
> 
> > Hello fellow hackers,
> >
> > I'd love to finally release (under the BSD license) my code for the revamped
> FreeBSD boot loader menu.
> >
> > Here's a detailed discussion of the release complete with pictures:
> > http://devinteske.com/new-freebsd-boot-loader-menu
> 
> Got it, nice simple install (as promised), and it worked like a charm.
> 
> I'd like to revisit the numbers vs. letters for menu options. IIRC (and I may
not),
> an earlier version used letters for the menu options, and people objected to
that
> change.

Looking at the CVS history of the Forth code that renders the menu, I'm
noticing:

a. FreeBSD-4.x and earlier didn't have a menu (after loading the kernel, the
loader simply drops to autoboot).

b. FreeBSD-5.x introduced the menu that is currently in-use today (rendered by
`beastie.4th').

c. The current menu uses numbers, not letters.

If there was an earlier version of the menu that used letters, I'm not seeing it
in CVS.


> 
> Since we're changing the menus, we ought to look at which is best for the end
> user, as opposed to just doing what feels comfortable to us as old users.
> 

I was thinking that what we ought to do is support *both* numbers *and* letters.

I envision the menuitem numbers remaining unchanged (1-7), allowing those
familiar with the numbers to use them.

However, as for the letters, I'm thinking that we *BOLD* the mnemonic in the
menuitem. For example (showing bolded items between asterisks):

1. Boot *[ENTER]*
2. *A*CPI Support: Enabled
3. Boot Safe Mode: NO
4. Boot *S*ingle User: NO
5. Boot *V*erbose: NO
6. *Esc*ape to loader prompt
7. *R*eboot

This should indicate to the user, for example if they see that the "V" in
"Verbose" is bolded, that they can press that key to activate that menuitem.

In addition, represented above, the only non-numeric keys that do anything would
be:

ENTER to boot
A to toggle ACPI support
S to toggle Single User mode
V to toggle Verbose boot
Esc to escape to the loader prompt
R to reboot

Looking at a standard QWERTY keyboard, A and S are close to each other, but
since the new menu is stateful (meaning that pressing the key merely changes the
state of that option) rather than stateless (wherein pressing a key would
immediately boot with that option), if you jam the wrong key, no worries (just
jam it again to return it to its pre-toggled state).

I'm open to discussion as to what the keys should be, though I'm pretty hard-set
on "S" for single-user, and "V" for verbose (the others, besides ENTER-to-boot,
are open for debate -- personally I think I'd be happy with nothing more than
just ENTER, "S" and "V" and no others).


> In particular, there was a study done around '80 (I tried to find it but
couldn't; I
> know of someone who can probably provide a reference if someone really wants
> it) that showed that menu selection with letters assigned mnemonically are
> easiest for users to memorize.

I can believe that quite easily. However, currently the boot menu does not
support such letters. I think this new loader menu is the perfect place to
implement them.

On another note, I have one other change that I'd like to get in... I noticed
that (in CVS) the menu currently blanks-out option #2 if booting on a system
where ACPI is disabled or unavailable. In my boot loader, I'd like to display
"ACPI Support: N/A" rather than simply blanking out the menu item.
-- 
Devin


> 
> Not really a major issue - you shouldn't be booting FreeBSD systems all that
> often, so it's not something I care very much about. However, I figure someone
> ought to at least speak up for using system that's better for new users rather
> than quietly doing it the old way since we're making a change anyway.
> 
> --
> Mike Meyer 
>   http://www.mired.org/consulting.html
> Independent Software developer/SCM consultant, email for more information.
> 
> O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

_

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.
_
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RELEASE] New Boot-Loader Menu

[Freddie Cash]

Very nice and functional, without adding a lot of extra verbosity or
steps.  I really appreciated the clean install via binary package.
Well done.

Only question I have is whether it's possible to use the Beastie ASCII
image instead of the pointy-eared blob?  The beastie.4th file is still
present under /boot, but I don't know how to hook it into the new
menu.

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RELEASE] New Boot-Loader Menu

[Warner Losh]

Why not both?



Warner

On Apr 29, 2011, at 11:08 AM, Mike Meyer wrote:

> On Sun, 24 Apr 2011 18:53:11 -0700
> Devin Teske  wrote:
> 
>> Hello fellow hackers,
>> 
>> I'd love to finally release (under the BSD license) my code for the revamped 
>> FreeBSD boot loader menu.
>> 
>> Here's a detailed discussion of the release complete with pictures:
>> http://devinteske.com/new-freebsd-boot-loader-menu
> 
> Got it, nice simple install (as promised), and it worked like a charm.
> 
> I'd like to revisit the numbers vs. letters for menu options. IIRC
> (and I may not), an earlier version used letters for the menu options,
> and people objected to that change.
> 
> Since we're changing the menus, we ought to look at which is best for
> the end user, as opposed to just doing what feels comfortable to us as
> old users.
> 
> In particular, there was a study done around '80 (I tried to find it
> but couldn't; I know of someone who can probably provide a reference
> if someone really wants it) that showed that menu selection with
> letters assigned mnemonically are easiest for users to memorize.
> 
> Not really a major issue - you shouldn't be booting FreeBSD systems
> all that often, so it's not something I care very much about. However,
> I figure someone ought to at least speak up for using system that's
> better for new users rather than quietly doing it the old way since
> we're making a change anyway.
> 
>-- 
> Mike Meyerhttp://www.mired.org/consulting.html
> Independent Software developer/SCM consultant, email for more information.
> 
> O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
> 
> 

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RELEASE] New Boot-Loader Menu

[Mike Meyer]

On Sun, 24 Apr 2011 18:53:11 -0700
Devin Teske  wrote:

> Hello fellow hackers,
> 
> I'd love to finally release (under the BSD license) my code for the revamped 
> FreeBSD boot loader menu.
> 
> Here's a detailed discussion of the release complete with pictures:
> http://devinteske.com/new-freebsd-boot-loader-menu

Got it, nice simple install (as promised), and it worked like a charm.

I'd like to revisit the numbers vs. letters for menu options. IIRC
(and I may not), an earlier version used letters for the menu options,
and people objected to that change.

Since we're changing the menus, we ought to look at which is best for
the end user, as opposed to just doing what feels comfortable to us as
old users.

In particular, there was a study done around '80 (I tried to find it
but couldn't; I know of someone who can probably provide a reference
if someone really wants it) that showed that menu selection with
letters assigned mnemonically are easiest for users to memorize.

Not really a major issue - you shouldn't be booting FreeBSD systems
all that often, so it's not something I care very much about. However,
I figure someone ought to at least speak up for using system that's
better for new users rather than quietly doing it the old way since
we're making a change anyway.

http://www.mired.org/consulting.html
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RELEASE] New Boot-Loader Menu

[Eitan Adler]

> I'd love to finally release (under the BSD license) my code for the revamped 
> FreeBSD boot loader menu.

Woot! Community contributions under a useful license :-)

> Here's the download:
> http://druidbsd.sourceforge.net/download/loader_menu-1.0.tgz

Painless installation - thanks!

>> And upon your next boot will use the new loader menu. A feature-complete 
>> sophisticated boot menu designed from the ground up.

The delay "loading boot menu" seems longer than it used to be. Perhaps
this is because I never paid attention or maybe because the "progress
bar" with the dots draws attention to it. Regardless this loader makes
a lot more sense to me than the original. I've always wanted to be
able to be into SUM && verbose logging or other combinations.

I tested this on a Lenovo G530 laptop and it seems to work fine with a
few different combinations as well as at the prompt.


Thanks for your work!



-- 
Eitan Adler
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RELEASE] New Boot-Loader Menu

[Devin Teske]

On Apr 25, 2011, at 8:30 AM, Eitan Adler wrote:

>> I'd love to finally release (under the BSD license) my code for the revamped 
>> FreeBSD boot loader menu.
> 
> Woot! Community contributions under a useful license :-)
> 
>> Here's the download:
>> http://druidbsd.sourceforge.net/download/loader_menu-1.0.tgz
> 
> Painless installation - thanks!
> 
>>> And upon your next boot will use the new loader menu. A feature-complete 
>>> sophisticated boot menu designed from the ground up.
> 
> The delay "loading boot menu" seems longer than it used to be. Perhaps
> this is because I never paid attention or maybe because the "progress
> bar" with the dots draws attention to it. Regardless this loader makes
> a lot more sense to me than the original. I've always wanted to be
> able to be into SUM && verbose logging or other combinations.
> 
> I tested this on a Lenovo G530 laptop and it seems to work fine with a
> few different combinations as well as at the prompt.
> 
> 
> Thanks for your work!

double-w00t! Time for the cake and punch!

Thank you for trying my work.
-- 
Devin

> 
> 
> 
> -- 
> Eitan Adler


_

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.
_
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RELEASE] New Boot-Loader Menu

[Gary Jennejohn]

On Sun, 24 Apr 2011 18:53:11 -0700
Devin Teske  wrote:

> I'd love to finally release (under the BSD license) my code for the
> revamped FreeBSD boot loader menu.
> 
> Here's a detailed discussion of the release complete with pictures: 
> http://devinteske.com/new-freebsd-boot-loader-menu
> 
> Here's the download: 
> http://druidbsd.sourceforge.net/download/loader_menu-1.0.tgz
> 
> The download is a FreeBSD package.  You can execute:
> 
> fetch [aboveURL] pkg_add loader_menu-1.0.tgz reboot
> 
> And upon your next boot will use the new loader menu.  A
> feature-complete sophisticated boot menu designed from the ground up.
> 

Although I personally never use the boot menu it's nice to see someone
trying to make it more usable for the average FreeBSD user.

-- 
Gary Jennejohn
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: New Boot-Loader

[Devin Teske]

On Mar 28, 2011, at 5:04 AM, Andriy Gapon wrote:

> 
> Would also be cool to have an option to boot "something else" (like e.g.
> memtest86).  Maybe a special directory with loadable binaries and a special 
> menu
> entry to select one of them.

As surprising as this release is, I've actually got plans to one day release 
our ISOLINUX based boot loader configuration that we use to do this very thing. 
We use the vesamenu.c32 module to present a menu containing memtest86 and many 
many other tools and at the top of that menu is our entry for chain-loading to 
FreeBSD (as a default).

> 
> Probably even better to have a mechanism for pluggable menu entries like a 
> special
> directory that would have .4th files each of which would represent one extra 
> menu
> option.  So instead of hacking system .4th files, one could easily extend main
> menu with custom entries.

My menu.4th module (that I released today -- see druidbsd.sf.net) does provide 
you with what you need to create not only an extended menu of your own design, 
but to create multiple menus through a system of separate .4th files. I in-fact 
actually used it to that very end in one of our custom boot menus. Each .4th 
file would call "menu-clear" and then set the appropriate "menu_caption[N]" 
variables, forming an array of values of 1-9 for N (9 is the maximum), before 
finally calling menu-create (which then read in the variables set in the 
environment and generating the menu). This is precisely one of the intended 
designs of my menu. It also has hooks for providing not only toggle-state menu 
options but cycle-state options (for example, setting "kernel[0]", "kernel[1]", 
and "kernel[2]", then having a menu item that upon keypress would allow cycling 
between the three (or more) options.

Though these advanced features and topics are not used in the distributed code, 
I did not remove the underlying functions that are required/used to enable such 
extended functionality. For example, you'll still find "cycle_menuitem" in 
menu.4th, though it's not used by anything (waiting for some enterprising soul 
like yourself to put it to use -- though on a side-note, we're still using 
these functions in our custom boot menus on our automated installers where we 
change out the logos, mascots, colors, and use the higher level functions not 
required in the standard FreeBSD boot process).

> 
> Just a dream...

Not a dream. I somehow think you were channeling our progress. That or great 
minds think alike.
-- 
Devin


> -- 
> Andriy Gapon

-- 
Cheers,
Devin Teske

-> CONTACT INFORMATION <-
Business Solutions Consultant II
FIS - fisglobal.com
510-735-5650 Mobile
510-621-2038 Office
510-621-2020 Office Fax
909-477-4578 Home/Fax
devin.te...@fisglobal.com

-> LEGAL DISCLAIMER <-
This message  contains confidential  and proprietary  information
of the sender,  and is intended only for the person(s) to whom it
is addressed. Any use, distribution, copying or disclosure by any
other person  is strictly prohibited.  If you have  received this
message in error,  please notify  the e-mail sender  immediately,
and delete the original message without making a copy.

-> END TRANSMISSION <-

_

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.
_
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

[RELEASE] New Boot-Loader Menu

[Devin Teske]

Hello fellow hackers,

I'd love to finally release (under the BSD license) my code for the revamped 
FreeBSD boot loader menu.

Here's a detailed discussion of the release complete with pictures:
http://devinteske.com/new-freebsd-boot-loader-menu

Here's the download:
http://druidbsd.sourceforge.net/download/loader_menu-1.0.tgz

The download is a FreeBSD package. You can execute:

fetch [aboveURL]
pkg_add loader_menu-1.0.tgz
reboot

And upon your next boot will use the new loader menu. A feature-complete 
sophisticated boot menu designed from the ground up.
-- 
Cheers,
Devin Teske



P.S. This code has been developed since 2006 and has been booted on hundreds of 
machines thousands of times by a group of more than two dozen field engineers 
trained to install, trouble-shoot, and maintain FreeBSD. It is only after this 
success that we are so happy to release this to the general public under the 
BSD license. Should it make its way into the base distribution, we would be 
honored, but that is not a necessity.

-> LEGAL DISCLAIMER <-
This message  contains confidential  and proprietary  information
of the sender,  and is intended only for the person(s) to whom it
is addressed. Any use, distribution, copying or disclosure by any
other person  is strictly prohibited.  If you have  received this
message in error,  please notify  the e-mail sender  immediately,
and delete the original message without making a copy.

-> FUN STUFF <-
-BEGIN GEEK CODE BLOCK-
Version 3.12
GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB$ P@$ L$ E-
W+++ N? o? K? w@ O M++$ V- PS+>++ PE@ Y+ PGP-> t(+) 5? X(+) R(-) tv+ b+>++ DI+
D+(++) G++ e> h r+++ z+++
--END GEEK CODE BLOCK--
http://www.geekcode.com/

-> END TRANSMISSION <-

_

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.
_
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: New Boot-Loader

[Arnaud Lacombe]

Hi,

On Mon, Mar 28, 2011 at 1:50 PM, Andrew Duane  wrote:
> -Original Message-
> From: owner-freebsd-hack...@freebsd.org 
> [mailto:owner-freebsd-hack...@freebsd.org] On Behalf Of Andriy Gapon
> Sent: Monday, March 28, 2011 8:00 AM
> To: Alexander Best
> Cc: FreeBSD Hackers
> Subject: Re: New Boot-Loader
>
> Please note that graphical loaders are not very serial console friendly ;-)
>
> --
> Andriy Gapon
>
>
> Amen, and we have a whole lot of platforms that are only serial consoles (and 
> 9600 baud at that).
FWIW, an interesting thing, from my point of view, would be to get rid
of that 9600bps limitation due to the use of INT14 in the first stage
bootloader to have access to more descent serial console speed in
early boot stage.

> Also, I like the letters instead of numbers for boot options, for those of us 
> that have known for years that "s" is single user mode, "v" is verbose, 
> etc
>
you can also have a thought to the people who are used to use numbers :)

- Arnaud

>
>
>  ...
> Andrew Duane
> Juniper Networks
> o   +1 978 589 0551
> m  +1 603-770-7088
> adu...@juniper.net
>
>
>
>
>
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: New Boot-Loader

[Alexander Best]

On Tue Mar 29 11, Bernd Walter wrote:
> On Mon, Mar 28, 2011 at 01:50:20PM -0400, Andrew Duane wrote:
> > -Original Message-
> > From: owner-freebsd-hack...@freebsd.org 
> > [mailto:owner-freebsd-hack...@freebsd.org] On Behalf Of Andriy Gapon
> > Sent: Monday, March 28, 2011 8:00 AM
> > To: Alexander Best
> > Cc: FreeBSD Hackers
> > Subject: Re: New Boot-Loader
> > 
> > Please note that graphical loaders are not very serial console friendly ;-)
> > 
> > -- 
> > Andriy Gapon
> > 
> > 
> > Amen, and we have a whole lot of platforms that are only serial consoles 
> > (and 9600 baud at that).
> > Also, I like the letters instead of numbers for boot options, for those of 
> > us that have known for years that "s" is single user mode, "v" is verbose, 
> > etc
> 
> This can hardly be an argument, because on serial consoles even
> the current full-screen implementation isn't friendly at all.
> One of the first things I always do is to disable beastie-start.
> As long as it is still based on ficl and can be disabled to get
> the traditional linemode I don't see a problem.

actually it's quite easy. there are two kind of people:

1) the ones that like it plain and simple and
2) the ones that fancy eye candy

lets have a boot loader for 1) which supports serial consoles and firewire
stuff and verbose booting and all that stuff one for 2).

> 
> -- 
> B.Walter  http://www.bwct.de
> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.

-- 
a13x
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: New Boot-Loader

[Bernd Walter]

On Mon, Mar 28, 2011 at 01:50:20PM -0400, Andrew Duane wrote:
> -Original Message-
> From: owner-freebsd-hack...@freebsd.org 
> [mailto:owner-freebsd-hack...@freebsd.org] On Behalf Of Andriy Gapon
> Sent: Monday, March 28, 2011 8:00 AM
> To: Alexander Best
> Cc: FreeBSD Hackers
> Subject: Re: New Boot-Loader
> 
> Please note that graphical loaders are not very serial console friendly ;-)
> 
> -- 
> Andriy Gapon
> 
> 
> Amen, and we have a whole lot of platforms that are only serial consoles (and 
> 9600 baud at that).
> Also, I like the letters instead of numbers for boot options, for those of us 
> that have known for years that "s" is single user mode, "v" is verbose, 
> etc

This can hardly be an argument, because on serial consoles even
the current full-screen implementation isn't friendly at all.
One of the first things I always do is to disable beastie-start.
As long as it is still based on ficl and can be disabled to get
the traditional linemode I don't see a problem.

-- 
B.Walter  http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: New Boot-Loader

[dieterbsd]

Please note that graphical loaders are not very serial console 

friendly ;-)

Yes!  Real computers have RS-232 consoles.  And please stick with
plain ASCII text.  The current bootloader is at best ugly and at
worst unusable on some terminals.  AFAIK the bootloader doesn't have
termcap/terminfo available.

The default needs to work everywhere.  A bootloader does not need to be 
pretty.
If you want a pretty bootloader, put it off to the side and those who 
both can

and want to run it can enable it once the basics are running.


___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: New Boot-Loader

[Andrew Duane]

-Original Message-
From: owner-freebsd-hack...@freebsd.org 
[mailto:owner-freebsd-hack...@freebsd.org] On Behalf Of Andriy Gapon
Sent: Monday, March 28, 2011 8:00 AM
To: Alexander Best
Cc: FreeBSD Hackers
Subject: Re: New Boot-Loader

Please note that graphical loaders are not very serial console friendly ;-)

-- 
Andriy Gapon


Amen, and we have a whole lot of platforms that are only serial consoles (and 
9600 baud at that).
Also, I like the letters instead of numbers for boot options, for those of us 
that have known for years that "s" is single user mode, "v" is verbose, etc


 ...
Andrew Duane
Juniper Networks
o   +1 978 589 0551
m  +1 603-770-7088
adu...@juniper.net

 



___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: New Boot-Loader

[Damien Fleuriot]

On 3/28/11 6:48 AM, Devin Teske wrote:
> Hi fellow hackers,
> 
> I'm designing an open-sourced replacement boot-loader for FreeBSD. I feel 
> that the existing options in the boot-loader menu today can be whittled down 
> significantly with a stateful menu system rather than a single-action item 
> menu system.
> 
> In designing the new menu, I'd like to get your opinions. From old:
> 
>   FreeBSD 8.1-RELEASE: twitpic.com/4e485w
> 
> to new:
> 
>   Replacement Boot-Loader: twitpic.com/4e46ol
> 
> NOTE: The final release will have a single-user mode option.
> 
> The new menu allows for more flexibility as selecting options 2 ("Boot 
> Verbose") or 3 ("ACPI Support") independently toggles the status, updates the 
> menu item, and redisplays the menu -- ever-waiting until the user ultimately 
> presses ENTER, "1", or escapes to the prompt and types "boot". Thus, one 
> could potentially launch single-user mode with verbosity on and ACPI disabled 
> (if one so desired).
> 
> In addition, I really tried to capture the essence of the new logo (spent 
> months off-and-on using different conversion programs with different inputs). 
> In the end, I found text-image.com produced the best result. I used the 
> official freebsd.org/logo.html Standard Logo (black and white), cropped (to 
> 122x123) and converted to jpeg with white background. I used an "Image Width" 
> of 45 in their "Convert into ASCII" program available here: 
> text-image.com/convert/ascii.html
> 
> I would be distributing this as an installable package (perhaps in the ports 
> tree if it gains popularity).


I like the new looks, thanks for your efforts :)

I also like Paul's idea of tying the actions (single, verbose) to
letters instead of numbers.


As for the comment about this "new" look not being modern enough, to be
honest I for one could care less.
I'm using servers, when I see this loader this usually means there's a
problem or I'm anticipating one.
So it looking fancy isn't really my top priority, I'd rather it be
functional and well thought-out.

Thanks again for your work Devin :)


--
dfl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: New Boot-Loader

[Devin Teske]

On Mar 28, 2011, at 7:03 AM, John Baldwin wrote:

> On Monday, March 28, 2011 12:48:03 am Devin Teske wrote:
>> Hi fellow hackers,
>> 
>> I'm designing an open-sourced replacement boot-loader for FreeBSD. I feel
>> that the existing options in the boot-loader menu today can be whittled down
>> significantly with a stateful menu system rather than a single-action item
>> menu system.
> 
> Are you reimplementing loader from scratch or just hacking on the 4th scripts 
> to display the menu, etc.?

The menu is implemented as a series of 4th modules. Here's an earlier version 
of the code which I've been using on my LiveDistro boot disc:

druidbsd.cvs.sourceforge.net/viewvc/druidbsd/druidbsd/druidbsd/mdroot/boot/


> 
>> In designing the new menu, I'd like to get your opinions. From old:
>> 
>>  FreeBSD 8.1-RELEASE: twitpic.com/4e485w
>> 
>> to new:
>> 
>>  Replacement Boot-Loader: twitpic.com/4e46ol
>> 
>> NOTE: The final release will have a single-user mode option.
>> 
>> The new menu allows for more flexibility as selecting options 2 ("Boot 
>> Verbose") or 3 ("ACPI Support") independently toggles the status, updates the
>> menu item, and redisplays the menu -- ever-waiting until the user ultimately
>> presses ENTER, "1", or escapes to the prompt and types "boot". Thus, one 
>> could
>> potentially launch single-user mode with verbosity on and ACPI disabled (if
>> one so desired).
> 
> This is good.  I think DFly already does this and I had a low priority item 
> on 
> my todo list to eventually implement this in the current menu myself.
> 

I think you'll like the Forth code that I've written. I strived to keep it 
clean and modular. IMHO I feel that it's really easy to change/enhance/extend 
based on the menu mechanics as seen in "menu.rc", and 
"include/menu-commands.4th".


> -- 
> John Baldwin

-- 
Cheers,
Devin Teske


-> LEGAL DISCLAIMER <-
This message  contains confidential  and proprietary  information
of the sender,  and is intended only for the person(s) to whom it
is addressed. Any use, distribution, copying or disclosure by any
other person  is strictly prohibited.  If you have  received this
message in error,  please notify  the e-mail sender  immediately,
and delete the original message without making a copy.

-> FUN STUFF <-
-BEGIN GEEK CODE BLOCK-
Version 3.12
GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB$ P@$ L$ E-
W+++ N? o? K? w@ O M++$ V- PS+>++ PE@ Y+ PGP-> t(+) 5? X(+) R(-) tv+ b+>++ DI+
D+(++) G++ e> h r+++ z+++
--END GEEK CODE BLOCK--
http://www.geekcode.com/

-> END TRANSMISSION <-

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: New Boot-Loader

[Warner Losh]

On Mar 28, 2011, at 5:08 AM, Alexander Best wrote:

> On Sun Mar 27 11, Warner Losh wrote:
>> 
>> 
>> On Mar 27, 2011, at 10:48 PM, Devin Teske wrote:
>>> Replacement Boot-Loader: twitpic.com/4e46ol
>>> 
>>> NOTE: The final release will have a single-user mode option.
>> 
>> This looks really cool.  Nice to see a fresh look for the boot loader...
> 
> sorry if we have different opinions on this matter, but i don't quite see
> the "fresh" look.
> 
> imo a "modern" boot loader looks like this
> 
> http://www.dailycupoftech.com/wp-content/uploads/2006/08/ubuntu01.png
> 
> or this
> 
> http://images.linuxscreenshots.com/distro/opensuse/11.3/h400/01_boot_menu.png
> 
> ... and not something made out of ascii chars like it's 1981. ;)

Fresh here means "not looking exactly like it has since 1995"...  Where we wind 
up might not be this prototype, but it should spur discussions.

Warner___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"