qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] hw/arm/boot: allow using a command line specifi


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] hw/arm/boot: allow using a command line specified dtb without a kernel
Date: Thu, 29 Sep 2016 18:58:37 -0700

On 22 September 2016 at 23:33, Michael Olbrich <address@hidden> wrote:
> On Thu, Sep 22, 2016 at 05:23:17PM +0100, Peter Maydell wrote:
>> On 10 September 2016 at 16:07, Michael Olbrich <address@hidden> wrote:
>> > diff --git a/vl.c b/vl.c
>> > index ee557a1d3f8a..bbea51e0ce7d 100644
>> > --- a/vl.c
>> > +++ b/vl.c
>> > @@ -4335,11 +4335,6 @@ int main(int argc, char **argv, char **envp)
>> >          exit(1);
>> >      }
>> >
>> > -    if (!linux_boot && qemu_opt_get(machine_opts, "dtb")) {
>> > -        error_report("-dtb only allowed with -kernel option");
>> > -        exit(1);
>> > -    }
>> > -
>>
>> I can see why you want this change, but what worries me a little
>> is that this is changing the behaviour of -dtb for all QEMU
>> target architectures, not just ARM (they no longer get a helpful
>> message on user error). I'm not sure how to address that, though.
>
> Would a 'if !arm' be possible or useful here?

It's not quite that simple :-)

I think we have two choices:
(1) just go ahead and remove the error-check, on the basis that:
 * for some boards -dtb is useful even without -kernel
 * -dtb might be ignored even with -kernel if the specified
   kernel isn't a DTB-aware kernel, but we ignore that
 * -dtb is ignored even with -kernel for target archs/boards
   which don't support or use DTB, and we don't warn about that
 * we don't warn about -kernel being useless for target boards
   that don't pay any attention to it
(2) add some kind of field to MachineClass indicating whether
   the machine can handle dtb files with/without a kernel
   (and perhaps also whether the machine supports -kernel at all),
   use that to gate the warning messages, and update all the
   machines to correctly indicate what they can or can't handle.
   This would let us give warning messages when the user asks
   for something we're going to ignore (including letting us
   fix up some of the cases we don't currently deal with as
   enumerated above), but it would be a fair chunk of effort
   for a fairly small user-friendliness gain

Thinking about it more, I'm inclining towards the simpler
option (1). Paolo, do you have an opinion here ?

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]