Re: [PATCH v2 10/10] x86, efi: EFI boot stub support

[Matt Fleming]

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/