On Montag, 3. Oktober 2022 14:50:04 CEST Daniel P. Berrangé wrote: > On Mon, Oct 03, 2022 at 02:46:04PM +0200, Christian Schoenebeck wrote: > > On Montag, 3. Oktober 2022 12:06:12 CEST Daniel P. Berrangé wrote: > > > The current message when using '-net user...' with SLIRP disabled at > > > > > > compile time is: > > > qemu-system-x86_64: -net user: Parameter 'type' expects a net backend > > > type > > > > > > (maybe it is not compiled into this binary) > > > > Is this intended as alternative to Marc-André's previous patch? > > This is a patch that should be applied regardless of any other change, > because the error message we report here today is awful and needs > improving. > > > If yes, > > then > > > > same applies here: what about people not passing any networking arg to > > QEMU? They would not get any error message at all, right? > > Yes, I mentioned that in the text that you've quoted below....
Yeah, missed that one, sorry. > > > An observation is that we're using the 'netdev->type' field here which > > > is an enum value, produced after QAPI has converted from its string > > > form. > > > > > > IOW, at this point in the code, we know that the user's specified > > > type name was a valid network backend. The only possible scenario that > > > can make the backend init function be NULL, is if support for that > > > backend was disabled at build time. Given this, we don't need to caveat > > > our error message with a 'maybe' hint, we can be totally explicit. > > > > > > The use of QERR_INVALID_PARAMETER_VALUE doesn't really lend itself to > > > user friendly error message text. Since this is not used to set a > > > specific QAPI error class, we can simply stop using this pre-formatted > > > error text and provide something better. > > > > > > Thus the new message is: > > > qemu-system-x86_64: -net user: network backend 'user' is not compiled > > > into > > > > > > this binary > > > > And why not naming the child, i.e. that QEMU was built without slirp? > > There are several network backends that can be conditionally disabled > at build time, and IMHO its overkill to give a different message for > each one. This message is sufficient to show users where to go next. Yes, but that is not a user friendly error message, especially for people who never dealt with QEMU's networking options before. That message does not make it obvious how to find the solution IMO. What about a web link to the QEMU networking docs where this issue could then be clarified in a more user friendly manner? #anchors_are_cheap > > > The case of passing 'hubport' for -net is also given a message reminding > > > people they should have used -netdev/-nic instead, as this backend type > > > is only valid for the modern syntax. > > > > > > Signed-off-by: Daniel P. Berrangé <berra...@redhat.com> > > > --- > > > > > > NB, this does not make any difference to people who were relying on the > > > QEMU built-in default hub that was created if you don't list any -net / > > > -netdev / -nic argument, only those using explicit args. > > .... here. > > > > With regards, > Daniel
