Re: [PATCH] x86 built-in command line (resend)

On Mon, Jul 31, 2006 at 12:35:16PM -0700, H. Peter Anvin wrote:
Matt Mackall wrote:
On Mon, Jul 31, 2006 at 12:07:02PM -0700, H. Peter Anvin wrote:
Matt Mackall wrote:
I'm resending this as-is because the earlier thread petered out
without any strong arguments against this approach. x86_64 patch to
follow.
"No strong arguments?"

I still maintain that this patch has the wrong priority in case more
than one set of arguments are provided.

But you still haven't answered how that lets you work around firmware
that passes parameters you don't like.


That a fairly unique problem, and is most likely in a minority
application. For that case a CONFIG option to ignore the
firmware-provided command line would make sense. I do not believe it
should be the only option or even the default.

It's not the default. The default is all args come from the
bootloader.

At the risk of repeating myself, here are all possible features and
behaviors carefully enumerated again:

Possible features:
a) allow dealing with bootloaders that don't pass arguments
b) allow dealing with bootloaders that pass bogus arguments
c) allow dealing with bootloaders that run up against length limits
d) allow dealing with bootloaders where changing arguments dynamically
is difficult
e) provide friendly defaults

Possible behaviors:
1) command line overrides built-in (won't work with b, works with the
rest)
2) built-in overrides command line (not so great for e, works with the
rest)
3) command line appends to built-in (generally broken as our command
parser can't arbitrarily override earlier arguments in most cases)
4) built-in appends to command line (same story)

Now I basically think behavior (e) is worthless. Embedded folks don't
care if the kernel's friendly and it's a solved problem for distros
too. Anyone else is building a kernel for themselves and don't need
defaults.

By comparison, the value of (b) is that you can control things you
otherwise can't.

It would be particularly good if this could be standardized across
architectures, which is another reason to do it right.

Yes. They should all clearly do (2).

--
Mathematics is the supreme nostalgia of our time.
-
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/

Relevant Pages

  • Re: -POWDER- Quizars Big Bag of Questions
    ... the RNG only wants to create cockatrices. ... I'm always suspicious of the need for such a command. ... the nice side effect of already dealing with interruptions) ... A dozen total hours of play or so, and I'm still not used to noun-verb. ...
    (rec.games.roguelike.misc)
  • Re: SQL Losing Data
    ... I'm just using the bound form's built-in save command. ... the user is selecting Save Record from Access' Records menu. ... >> click into another area and the information doesn't get lost. ...
    (microsoft.public.sqlserver.odbc)
  • Re: Perl on Windows question
    ... I think you just helped me solve my problem, Sinan. ... program that Perl was using in backticks was the Unix-ish "type" ... not the DOS built-in "type" command. ...
    (comp.lang.perl.misc)
  • [PATCH] bootup: Add built-in kernel command line for x86
    ... Add support for a built-in command line for x86 architectures. ... The default behavior is to append the boot loader string ...
    (Linux-Kernel)
  • Re: Convert Table to Text-dialog missing
    ... Any macro with the same name as a built-in command will ... This reply is posted in the Newsgroup; please post any follow question or reply ...
    (microsoft.public.word.tables)