On 13/10/2016 13:50, Marc-André Lureau wrote:
> Hi
> ----- Original Message -----
>> On 13/10/2016 13:14, Marc-André Lureau wrote:
>>> Hi,
>>> Commit 949055a2 "char: use a fixed idx for child muxed chr" introduced
>>> a regression in mux usage, since it wrongly interpreted mux as muxing
>>> various chr backend. Instead, it muxes frontends.
>>> The first patch reverts the broken change, the following patches add
>>> tracking to frontend handler, finally the last patch adds some tests
>>> that would have helped to track the crash and the regression. There is
>>> also a small fix for ringbuf.
>> In general I like the solution, but I dislike the API.
>> Would it work if we had something like
>>     struct CharBackend {
>>         CharDriverState *chr;
>>         int tag;
>>     }
> You mean front-end right?

The front-end is in hw/char.  The back-end as seen by the front-end is a
(chr, tag) pair---so that struct should be CharBackend.  The actual
back-end is the CharDriverState, but the front-end doesn't know.

I guess you can keep the qemu_chr_fe_* naming convention, which is
confusing anyway...

>> and we modified all qemu_chr_fe_* functions (plus
>> qemu_chr_add_handlers[1]) to take a struct CharBackend.  chardev
>> properties would also take a struct CharBackend.  Then removing handlers
>> can still be done in release_chr, making the patches much smaller.
> As long as they use chardev property, it's not always the case.
>> The conversion is a bit tedious, but I think it's much easier compared
> Yes, it's tedious :) Do you mind if I try to make the change on top? If it 
> really reduces the patch 4/7, we could try to squash it?

You can always start the development like that, I won't notice.  If you
squash everything together and re-separate the patches from scratch at
the end, I won't notice either. :)

But note that for example you don't need to do all the new unrealize
stuff, so perhaps you can start by undoing that in patch 4.

>> to patch 4.  I feel bad for having you redo everything and in particular
>> patch 7, but this is the model that the block layer uses and it works
>> very well there.
> Which function btw?

I'm thinking of the separation between BlockBackend and
BlockDriverState.  BlockBackend started as a very thin veneer over
BlockDriverState, but we've moved functionality out of BDS slowly
whenever it made sense.


>> [1] while at it, it's probably best to rename qemu_chr_add_handlers
>>     to qemu_chr_fe_add_handlers as the first patch in the series,
>>     so that qemu_chr_add_handlers(CharDriverState *chr, ..., int tag)
>>     can take the role of qemu_chr_set_handlers in this series.

Reply via email to