On 08.02.2012, at 14:30, Peter Crosthwaite wrote:
>
>
> On Wed, Feb 8, 2012 at 11:10 PM, Alexander Graf <ag...@suse.de> wrote:
>
> On 08.02.2012, at 14:04, Peter Crosthwaite wrote:
>
>>
>>
>> On Wed, Feb 8, 2012 at 10:41 PM, Alexander Graf <ag...@suse.de> wrote:
>>
>> On 08.02.2012, at 13:27, Paul Brook wrote:
>>
>> >> 2012/2/8 Paul Brook <p...@codesourcery.com>
>> >>
>> >>>>> I suspect we want to replace the arm_load_kernel call with an
>> >>>>> arm_linux_loader device with appropriate properties.
>> >>>>
>> >>>> Ok, so does this mean the machine model would still explicitly
>> >>>> instantiate the bootloader device?
>> >>>
>> >>> Yes. Bootloaders inherently have machine specific knowledge. They need
>> >>> to know ram location, board ID, secondary CPU boot protocols, etc.
>> >>> Requiring the user specify all these things separately from the rest of
>> >>> the machine description is IMO not acceptable.
>> >>
>> >> So what im suggesting here is that machines export these properties to a
>> >> globally accessible location. Perhaps via the machine opts mechanism? Then
>> >> we are in a best of both worls situation where machine models do not need
>> >> bootloader awareness yet bootloaders can still query qemu for ram_size,
>> >> smp#, board_id and friends.
>> >
>> > Hmm, I suppose this might work. I'm not sure what you think the benefit of
>> > this is though. Fact is the machine needs to have bootloader awareness,
>> > whether it be instantating an object or setting magic variables.
>> > Having devices rummage around in global state feels messy. I'd much rather
>> > use actual properties on the device. IMO changing the bootloader is
>> > similar
>> > complexity to (say) changing a UART. i.e. it's a board-level change not an
>> > end-user level change. Board-level changes are something that will happen
>> > after QOM conversion, i.e. when we replace machine->init with a board
>> > config
>> > file.
>>
>>
>> Yeah, basically the variable flow goes:
>>
>> vl.c -> machine_opts -> machine_init() -> device properties -> device_init()
>>
>> So that the machine init function that creates the bootloader device
>> enumerates the machine_opts (just like is done in Peter's patches) and then
>> passes those on to the bootloader device as device properties.
>>
>>
>> So in patch 4/4 in Peters series where he adds a new bootloader feature (the
>> -dtb switch) its done slightly differently, the machine model does not
>> handle the machine_opts at all, i.e. The machine model has no awareness of
>> this dtb argument. Instead the arm boot loader directly queries the
>> machine_opts API itself:
>>
>> @@ -251,6 +317,9 @@ void arm_load_kernel(CPUState *env, struct arm_boot_info
>> *info)
>> exit(1);
>> }
>>
>> + info->dtb_filename =
>> qemu_opt_get(qemu_opts_find(qemu_find_opts("machine"),
>> + 0), "dtb");
>> +
>>
>> There is no path through the machine_init for this particular property.
>
> Ah, I see. So he derived from the original proposal, oh well :).
>
>
> Isn't this the best approach tho? If you changed it over to the other flow,
> then you would end up with a change pattern where every machine model would
> need to get and pass the new argument. This way the diff is limited to the
> command line infrastructure and the bootloader.
If you want the smallest diff, just make things globals and call it a day. This
whole thing is a discussion around device architecture, right?
>
>> What I am suggesting is that a similar approach is take for machine model
>> set properties (such as ram_size), but instead of the command line setting
>> the props its done by the machine model. The machine model qemu_opt_set()
>> the ram_size = whatever. Then the bootloader qemu_opt_get()s it. If you did
>> this for the key properties related to boot then you would remove the need
>> for machines to have awareness of their boot process.
>
> But that's exactly what we want. We want the machine to be aware of its boot
> process, because that's the one place that needs to instantiate the boot
> device, no?
>
>
> More a case of the reverse isnt it? The bootloader needs to know about the
> machine its generating code for, but the machine generation process doesnt
> need to know about the software its going to run. The machine being aware of
> the bootloader implementation and instantiating it you are putting in place a
> policy where you forcing a particular bootflow on every user of that machine.
> The hardware is placing policy on what software its running.
>
> In the case of arm boot you end up with a situation where you are trying to
> write a bootloader that can handle every possible scenario, what I am
> suggesting is arm_boot.c as it is becomes a linux specific bootloader and
> other bootflows such as booting from elfs or raw images (or other unforseen
> bootflows) are different bootloader devices. The choice of which bootloader
> you use is driven by which -device you put down on command line.
Hrm. I wouldn't want to have to select different bootloader types using
-device. Today, we have autodetect code in almost all targets that checks the
binary and figures out what to load from it. So on x86 you just do -kernel foo
and if foo is a Linux kernel, it will run it using that loader, while if it's a
multiboot image, it will load it through that.
Any reason you can't just upstream your specific bootloader code? We can then
worry about replacing the loader device at a different point in time and model
things easily now.
Alex
