lkml.org 
[lkml]   [2011]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2 10/10] x86, efi: EFI boot stub support
From
Date
On Sat, 2011-09-17 at 14:12 +0200, Maarten Lankhorst wrote:
> Anyhow it seems the cmdline_size is meant for reading, and setting it
> is completely ignored, see below. Could we make it a static array so
> no allocation needs to be done?

D'oh. Yeah, you're right, there's no point in updating cmdline_size.

What would be the benefit of making cmdline a static array and skipping
the allocation? I doubt it would improve boot time, and we'd end up
making the bzImage larger.

> > Hmm... I'm really not convinced that we need to support ASCII cmdline
> > arguments, sorry. efibootmgr has support for UCS-2, so that's what
> > should be used.
> >
> I know, but this is nicer for displaying, compare this efibootmgr -v output:
>
> Boot0002* Linux ASCII Boot HD(...)File(\vmlinuz.efi)root=/dev/sdb2 console=ttyS0,115200n8.
> Boot0003* Linux UCS-2 Boot HD(...)File(\vmlinuz.efi)r.o.o.t.=./.d.e.v./.s.d.b.2. .c.o.n.s.o.l.e.=.t.t.y.S.0.,.1.1.5.2.0.0.n.8...
>
> And it's more foolproof, since it's easy to pass strings as
> ASCII since it's the default, and it would show up readable in efibootmgr.

But if you don't like the output from efibootmgr, you should fix
efibootmgr, not cram more string manipulation code into the EFI stub.

If there were other cases where an ASCII cmdline was passed to the stub
I'd be more inclined to support it. But if it's just a case of "the EFI
boot stub doesn't parse arguments when efibootmgr passes them as ASCII"
my response is "Pass them as UCS-2 then".

--
Matt Fleming, Intel Open Source Technology Center



\
 
 \ /
  Last update: 2011-09-21 13:59    [W:0.053 / U:8.512 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site