Re: [Qemu-arm] [Qemu-devel] [PATCH] hw/arm/boot: allow using a command line specified dtb without a kernel

[Stefan Hajnoczi]

On Thu, Sep 29, 2016 at 06:58:37PM -0700, Peter Maydell wrote:
> 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 ?

The error check doesn't seem worth the effort.  It's a convenience
message to notify users that their configuration is broken but we can't
detect all the cases where it's broken.  It doesn't seem like a good
business to be in :).

Stefan

signature.asc
Description: PGP signature