headers
Devin Teske | 1 May 2011 01:00

RE: [RELEASE] New Boot-Loader Menu


> -----Original Message-----
> From: owner-freebsd-hackers <at> freebsd.org [mailto:owner-freebsd-
> hackers <at> freebsd.org] On Behalf Of Dieter BSD
> Sent: Saturday, April 30, 2011 12:28 PM
> To: freebsd-hackers <at> 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.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Dieter BSD | 1 May 2011 03:10

Re: [RELEASE] New Boot-Loader Menu

> 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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jason Hellenthal | 1 May 2011 05:11

Re: [RELEASE] New Boot-Loader Menu


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 <at>  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
(Continue reading)

Permalink | Reply | 6 comments |
headers
Devin Teske | 1 May 2011 05:38

Re: [RELEASE] New Boot-Loader Menu


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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Devin Teske | 1 May 2011 05:45

Re: [RELEASE] New Boot-Loader Menu


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 <at>  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
(Continue reading)

Permalink | Reply | 5 comments |
headers
rank1seeker | 1 May 2011 13:19
Picon

Re: Look of boot2, on HDD

> On 30.04.2011 20:39, rank1seeker <at> gmail.com wrote:
> >> Garrett Cooper wrote:
> >>> 2011/4/29<rank1seeker <at> gmail.com>:
> >>>> /boot/boot2    STAGE 2 bootstrap file
> >>>> Understands the FreeBSD file system enough, to find files on it, and 
can provide a simple interface to choose the kernel or loader to run.
> >>>>
> >>>> Once sys is fully booted, HDD is 'ada0'.
> >>>> However, STAGE 2, sees it, as a 'ad4', at boot process, which is 
same seen, by booted sys, when I turn off AHCI.
> >>>>
> >>>> So, here is the riddle ...
> >>>> On fully booted sys, how do I query STAGE 2, to tell me, how it'll 
see, my 'ada0' HDD?
> >>>
> >>>      This is a very interesting catch:
> >>>
> >>> /usr/src/sys/boot/pc98/boot2/boot2.c:static const char *const
> >>> dev_nm[NDEV] = {"ad", "da", "fd"};
> >>> /usr/src/sys/boot/i386/boot2/boot2.c:static const char *const
> >>> dev_nm[NDEV] = {"ad", "da", "fd"};
> >>>
> >>>      It probably will be a no-op soon because of some of the
> >>> compatibility changes Alex made, but still a potential point of
> >>> confusion nonetheless.
> >>
> >> Pardon my ignorance, but could somebody shed some light for me on this
> >> list of names? Why much more sophisticated loader(8) operates disks as
> >> diak0/1/..., while boot2 tries to mimic something he has no any idea
> >> about, using very limited information from random sources? Does this
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Möller | 1 May 2011 16:45

Re: [LIBC] Modfied Version of sscanf

Am 01.05.11 00:53 schrieb "Daniel O'Connor" unter <doconnor <at> gsoft.com.au>:

Thanks for your reply.
Ok, another example. I try to parse a request, coming from a client in the
form:
    GET <resource> HTTP/1.1.

It is expected that <resource> can contain space characters (even if
its not the case in reality).

How would you do that with sscanf ?

With regards,
Martin
> 
> On 01/05/2011, at 2:14, Martin Möller wrote:
>> outputs total garbage on my FreeBSD-7.0-RELEASE #0 amd64.
>> Is there already a way to do this or should we release a new version of
>> sscanf, e.g. called sscanfWS.
>> 
>> This modified version would output: Test 2->Test 3.
> 
> I think it does what it should.. %s is supposed to stop at whitespace.
> 
> You probably really want..
> 
> #include <stdio.h>
> #include <stdlib.h>
> #include <sys/types.h>
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jilles Tjoelker | 1 May 2011 18:29
Picon
Favicon

Re: [LIBC] Modfied Version of sscanf

On Sat, Apr 30, 2011 at 06:44:43PM +0200, Martin Möller wrote:
> This is my first email to this list, so hello to all members.
> The current version of sscanf, stops when a whitespace characters occurs in
> a string
> when the "%s" (string) type is used.

> The following code:

> char name [20], value [20];
> sscanf ("Test 2->Test 3", "%s->%s", name, value);
> printf ("%s->%s\n", name, value);

> outputs total garbage on my FreeBSD-7.0-RELEASE #0 amd64.
> Is there already a way to do this or should we release a new version of
> sscanf, e.g. called sscanfWS.

> This modified version would output: Test 2->Test 3.

I think you should use functions like memchr(), strchr() and strtok_r()
rather than sscanf().

For one, your code has undefined behaviour if the name or the value
exceed 19 bytes. If the input is untrusted, as your follow-up seems to
indicate, this undefined behaviour likely manifests in allowing an
attacker to execute code of his own choosing. Even if you avoid the
buffer overflow using a format string like "%19s->%19s" it is still not
very good as you may not get an error if the string is too long. Silent
truncation might invalidate security checks done elsewhere and can lead
to hard-to-diagnose bugs.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Diane Bruce | 1 May 2011 18:25

Re: [LIBC] Modfied Version of sscanf

On Sun, May 01, 2011 at 04:45:14PM +0200, Martin M?ller wrote:
> Am 01.05.11 00:53 schrieb "Daniel O'Connor" unter <doconnor <at> gsoft.com.au>:
> 
> Thanks for your reply.
> Ok, another example. I try to parse a request, coming from a client in the
> form:
>     GET <resource> HTTP/1.1.
> 
> It is expected that <resource> can contain space characters (even if
> its not the case in reality).
> 
> How would you do that with sscanf ?

You don't. You write a tokeniser and parser.
You are trying to misuse sscanf.

- Diane
--

-- 
- db <at> FreeBSD.org db <at> db.net http://www.db.net/~db
  Why leave money to our children if we don't leave them the Earth?
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
Martin Möller | 2 May 2011 14:13

Re: [LIBC] Modfied Version of sscanf

Hello,

Thanks for all the replies.
We have so far discovered the following suggetions for the parsing Problem:
Using: 
    o a tokenizer/parser is too much overhead for such a simple task
    o strchr, memchr is too low-level and not elegant enough
    o strtok would not even parse (tokenize) this simple example
    o a regexp library: How would you solve the problem with a regexp lib ?

Criteria:
    o Receive the value of <resource>
    o Check the Environment: Is <resource> really sourrounded by 'GET ' and
      'HTTP/1.1' ?!

I need a function which accepts BNF-style rules.
E.g.:
    char resource [512];

    ret = bnfparse (request, "GET %s HTTP/1.1", resource);

Ret would be $(NUMBER OF FORMAT SPECIFIERS, successfully handled) +env.
Env would be 1 if the Environment passes, and 0 is not.

Any comments ?
Best regards,
Martin

_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
(Continue reading)

Permalink | Reply | 9 comments |

Gmane