From: James Hogan <james.hogan@imgtec.com>
To: Arnd Bergmann <arnd@arndb.de>, Jonas Bonn <jonas.bonn@gmail.com>,
Ralf Baechle <ralf@linux-mips.org>,
Grant Likely <grant.likely@secretlab.ca>
Cc: linux-arch <linux-arch@vger.kernel.org>, Will <will.newton@imgtec.com>
Subject: Re: What's the deal with the different boot command lines?
Date: Fri, 4 Jan 2013 10:26:42 +0000 [thread overview]
Message-ID: <50E6AE62.7020501@imgtec.com> (raw)
In-Reply-To: <50BCDC93.4080100@imgtec.com>
Ping. Any comments on this?
On 03/12/12 17:08, James Hogan wrote:
> Hi,
>
> I've been trying to figure out how the various copies of the command
> line are handled and what they're for, to figure out what the best thing
> to do is to avoid getting the same cmdline twice when
> early_init_dt_scan_chosen falls back to CONFIG_CMDLINE. As far as I can
> tell from the generic code:
>
> setup_arch() is expected to set
> * boot_command_line
> * the pointer pointed to by it's argument (which goes into
> start_kernel()'s command_line variable).
>
> What is the intention of both of these command lines? Are they supposed
> to be the same, or different, or what?
>
> boot_command_line:
> * passed to parse_args("early options", ...)
> * gets printed
> * copied to saved_command_line, which is copied to static_command_line
> and used for parsing args at each init level
>
> command_line:
> * copied to static_command_line first, and passed to parse_args("Booting
> kernel", ...)
>
> Some interesting architecture's setup_arch() behaviour that I've noticed:
>
> Openrisc appears to set command_line to CONFIG_CMDLINE, but gets
> boot_command_line from the devicetree chosen.bootargs, which defaults to
> CONFIG_CMDLINE. So it appears that it provides different values. Was
> this intentional?
>
> MIPS appears to use of_scan_flat_dt to set arcs_cmdline from the
> devicetree (this will default to CONFIG_CMDLINE). CONFIG_CMDLINE may
> then be appended again in arch_mem_init. This is the same problem we
> have with metag. I'm of the opinion that of_scan_flat_dt is doing the
> wrong thing in falling back to CONFIG_CMDLINE, but maybe I misunderstand
> and it just doesn't matter if command line options are repeated. Any
> thoughts?
>
> Thanks
> James
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arch" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
prev parent reply other threads:[~2013-01-04 10:27 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-03 17:08 What's the deal with the different boot command lines? James Hogan
2013-01-04 10:26 ` James Hogan [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50E6AE62.7020501@imgtec.com \
--to=james.hogan@imgtec.com \
--cc=arnd@arndb.de \
--cc=grant.likely@secretlab.ca \
--cc=jonas.bonn@gmail.com \
--cc=linux-arch@vger.kernel.org \
--cc=ralf@linux-mips.org \
--cc=will.newton@imgtec.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).