qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v4 6/8] chardev/char-mux: implement backend chardev multiplex


From: Roman Penyaev
Subject: Re: [PATCH v4 6/8] chardev/char-mux: implement backend chardev multiplexing
Date: Fri, 17 Jan 2025 09:03:47 +0100

Hi Kevin,

On Thu, Jan 16, 2025 at 12:27 PM Kevin Wolf <kwolf@redhat.com> wrote:
>
> Am 17.12.2024 um 11:32 hat Roman Penyaev geschrieben:
> > Hi Markus,
> >
> > Thanks for the explicit info. But I have a lot to ask :)
> > Do I understand correctly that there are two ways to parse
> > arguments: classic, via qemu_opts_parse_noisily() and modern, via
> > qobject_input_visitor_new_str()? (for example, I look in
> > net/net.c, netdev_parse_modern()). My goal is not to create a
> > completely new option, but to add (extend) parameters for
> > chardev, namely to add a new type of backend device. This
> > complicates everything, since chardev uses
> > qemu_opts_parse_noisily() for parsing and bypasses the modern
> > way (I hope I'm not mistaken, maybe Marc can comment). And I'm
> > not sure that it's easy to replace the classic way of parsing
> > arguments with the modern way without breaking anything.
>
> A few years ago, I tried to unify the QMP and CLI code paths for
> creating chardevs and this involved using QAPI for everything. As far as
> I can remember, chardevs don't use any of the QemuOpts features that
> don't exist in they keyval parser, so it's easy from that angle.
>
> What makes it more complicated is that CLI and QMP options have diverged
> quite a bit, and while generally the same functionality is available, it
> sometimes uses different names or is negated in one compared to the
> other etc.

Right, I noticed that as well.

>
> So I ended up writing compatibility code that translated legacy CLI
> options into QAPI-compatible ones, and then I could use the exising QAPI
> types. Part of it made use of aliases, which would have been a new
> feature in QAPI, but Markus didn't like them in the end. They could have
> been replaced by manual conversion code, but I didn't have time (nor, to
> be honest, motivation) to work it any more when Markus had finally made
> that decision. It shouldn't actually be very hard.
>
> Anyway, if it's of any use for you, feel free to resurrect parts of it:
>
> https://repo.or.cz/qemu/kevin.git/shortlog/refs/tags/qapi-alias-chardev-v4

Nice, thanks for sharing, will take a look.

>
> (Or maybe I will eventually...)
>
> Whatever you choose to do, my one request for you would be that you
> really make sure that CLI and QMP are structured and behave exactly the
> same with your new option, to avoid making the problem worse than it
> already is.

I understand this as keeping compatibility between CLI and QAPI at the
command line interface level. In simple words: a new command line option
"list.0=id0,list.1=id1" should be parsed in CLI exactly as QAPI will parse
it in the possible bright future (I mean once the whole chardev is switched
to QAPI). If my understanding is correct, then, with Markus and Mark-Andre
help, I'm on the right track.

--
Roman



reply via email to

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