On 2012-10-08 19:07, Aurelien Jarno wrote:
> On Mon, Oct 08, 2012 at 08:52:30AM +0200, Jan Kiszka wrote:
>> On 2012-10-06 04:13, Peter Maydell wrote:
>>> On 5 October 2012 19:01, Jan Kiszka wrote:
I'm not a fan of this either, but the alternatives are way more
complicated. We either need
On Mon, Oct 08, 2012 at 08:52:30AM +0200, Jan Kiszka wrote:
> On 2012-10-06 04:13, Peter Maydell wrote:
> > On 5 October 2012 19:01, Jan Kiszka wrote:
> >> I'm not a fan of this either, but the alternatives are way more
> >> complicated. We either need to rewrite the chardev subsystem,
> >> specif
On 2012-10-08 18:28, Paolo Bonzini wrote:
> Il 08/10/2012 18:02, Peter Maydell ha scritto:
It's not (only) about a missing event for the serial frontend, it's also
about a spurious open event to the monitor. That generates unwanted
output during startup.
>> Right, so whatever's sendi
Il 08/10/2012 18:33, Peter Maydell ha scritto:
> On 5 October 2012 18:30, Jan Kiszka wrote:
>> This is nasty, but there is no better way given current mux logic:
>>
>> As setting up the block device will trigger a qemu_bh_poll while there
>> are qemu_chr open events in the queue, we have to regist
On 5 October 2012 18:30, Jan Kiszka wrote:
> This is nasty, but there is no better way given current mux logic:
>
> As setting up the block device will trigger a qemu_bh_poll while there
> are qemu_chr open events in the queue, we have to register the UARTs
> and everything else that might be mux'
Il 08/10/2012 18:02, Peter Maydell ha scritto:
>> > It's not (only) about a missing event for the serial frontend, it's also
>> > about a spurious open event to the monitor. That generates unwanted
>> > output during startup.
> Right, so whatever's sending that event needs not to do so until
> crea
On 8 October 2012 16:28, Jan Kiszka wrote:
> It's not (only) about a missing event for the serial frontend, it's also
> about a spurious open event to the monitor. That generates unwanted
> output during startup.
Right, so whatever's sending that event needs not to do so until
creation of the mac
On 2012-10-08 17:18, Paolo Bonzini wrote:
> Il 08/10/2012 08:52, Jan Kiszka ha scritto:
>> On 2012-10-06 04:13, Peter Maydell wrote:
>>> On 5 October 2012 19:01, Jan Kiszka wrote:
I'm not a fan of this either, but the alternatives are way more
complicated. We either need to rewrite the c
Il 08/10/2012 08:52, Jan Kiszka ha scritto:
> On 2012-10-06 04:13, Peter Maydell wrote:
>> On 5 October 2012 19:01, Jan Kiszka wrote:
>>> I'm not a fan of this either, but the alternatives are way more
>>> complicated. We either need to rewrite the chardev subsystem,
>>> specifically how mux'ed de
On 2012-10-06 04:13, Peter Maydell wrote:
> On 5 October 2012 19:01, Jan Kiszka wrote:
>> I'm not a fan of this either, but the alternatives are way more
>> complicated. We either need to rewrite the chardev subsystem,
>> specifically how mux'ed devices are registered and how the active one is
>>
On 5 October 2012 19:01, Jan Kiszka wrote:
> I'm not a fan of this either, but the alternatives are way more
> complicated. We either need to rewrite the chardev subsystem,
> specifically how mux'ed devices are registered and how the active one is
> selected. Or we need to avoid flushing "unrelate
On 2012-10-05 19:42, Peter Maydell wrote:
> On 5 October 2012 18:30, Jan Kiszka wrote:
>> This is nasty, but there is no better way given current mux logic:
>>
>> As setting up the block device will trigger a qemu_bh_poll while there
>> are qemu_chr open events in the queue, we have to register th
On 5 October 2012 18:30, Jan Kiszka wrote:
> This is nasty, but there is no better way given current mux logic:
>
> As setting up the block device will trigger a qemu_bh_poll while there
> are qemu_chr open events in the queue, we have to register the UARTs
> and everything else that might be mux'
This is nasty, but there is no better way given current mux logic:
As setting up the block device will trigger a qemu_bh_poll while there
are qemu_chr open events in the queue, we have to register the UARTs
and everything else that might be mux'ed first so that the right active
frontend is already
14 matches
Mail list logo
