On Thu, Sep 29, 2016 at 06:58:37PM -0700, Peter Maydell wrote:
> On 22 September 2016 at 23:33, Michael Olbrich <m.olbr...@pengutronix.de>
> wrote:
> > On Thu, Sep 22, 2016 at 05:23:17PM +0100, Peter Maydell wrote:
> >> On 10 September 2016 at 16:07, Michael Olbrich <m.olbr...@pengutronix.de>
> >> 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
