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'
13 matches
Mail list logo
