So on the topic of these command line arguments for initrd, dtb and friends, another related issue we have encountered (and have hacked around in our tree) is not being able to relocate the initrd or kernel. Currently these memory locations are hardcoded in arm_boot.c:
#define KERNEL_ARGS_ADDR 0x100
#define KERNEL_LOAD_ADDR 0x00010000
#define INITRD_LOAD_ADDR 0x00d00000
If you see patch 6/7 in this same series I put in place a hack to override the initrd location in memory, but I wonder if instead this should go up to the command line interface as a parameter. Currently the machine model (or arm_boot.c) defines exactly where kernels/initrds/command-line-args line in memory, but since these are software properties should perhaps they go up to the command line as -kernel,foo=bar options? E.G:
qemu-system-arm -kernel,kernel-image=/foo/zImage,kernel-addr=0x00010000,initrd=/foo/initrd,initrd_addr=0x00d00000
It strikes me as broken that a machine model specifies where in memory a kernel has to live. Something similar would apply to the dtb argument, this patch introduces.
For the next revision of this patch series I am going to put in the mollyguard and just use -kernel-dtb foo for the moment.
So with the greater issue of linux specific command line arguments, what is the consensus here on how this is going to be handled with regards to:
-Passing all this command line stuff in a struct
-nesting initrd and friends under the -kernel option.
And do either of these act as a blocker on this patch series?
Regards,
Peter
On Fri, Jan 27, 2012 at 6:25 PM, Markus Armbruster
<address@hidden> wrote:
Eric Blake <
address@hidden> writes:
> On 01/26/2012 12:34 PM, Scott Wood wrote:
>> On 01/24/2012 12:23 PM, Stefan Weil wrote:
>>> I'd prefer a different solution. As far as I have understood,
>>> the dtb is only useful with a kernel, so it could be handled
>>> as an optional attribute to the -kernel parameter:
>>>
>>> -kernel IMAGE[,dtb=DTB]
>>>
>>> Of course the same applies to -append, but that's a different issue.
>>
>> -initrd as well.
>>
>> This would mean you couldn't have a comma in a filename (shouldn't come
>> up often, but still ugly).
>
> In other instances where you use a comma to separate arguments and also
> want to accept commas in arbitrary file names, qemu has used the notion
> of a double comma as being the escape sequence for a single comma in the
> intended file name, rather than a separator for later arguments.
syntactic conventions.