On (Wed) Nov 04 2009 [10:39:39], Jan Kiszka wrote: > Amit Shah wrote: > > On (Tue) Nov 03 2009 [19:53:43], Jan Kiszka wrote: > >> Amit Shah wrote: > >>> On (Tue) Nov 03 2009 [23:25:52], Amit Shah wrote: > >>>> On (Tue) Nov 03 2009 [18:08:57], Jan Kiszka wrote: > >>>>> Amit Shah wrote: > >>>>>> The initial_reset sent to chardevs doesn't do much other than setting > >>>>>> a bool to true. Char devices are interested in the open event and > >>>>>> that gets sent whenever the device is opened. > >>>>> Have you checked with the monitor in all use cases (dedicated & muxed > >>>>> console, stdio & SDL console, etc.)? It was introduced once to fix a > >>>> I've checked with -monitor stdio, monitor in SDL and also chardevs using > >>>> unix sockets. > >>>> > >>>> I've not tried mux yet; I'll try that and report back. BTW if it ends up > >>>> not working with this patch, it'd be broken in the current master as > >>>> well. > >>> I tried with: > >>> > >>> -chardev stdio,mux=on,id=mux -monitor chardev:mux -serial chardev:mux > >>> > >>> The monitor prompt shows up as does the serial output. > >>> > >>> (btw I've also tried closing and opening char devs and that works fine > >>> too) > >> That sounds good. Then something must have changed since 2970a6c943, do > >> you see what? > > > > I think that depended on the resets being sent. I've now removed the > > need for resets altogether. > > No, this is in fact the reason why we no longer need it: > > 9a1e948129 (Introduce contexts for asynchronous callbacks) > > As the initial reset of the char device that is marked pending on open > is now no longer consumed by the IDE initialization, we can actually > drop the later regeneration via qemu_chr_initial_reset. I just hope this > stays like it is...
I tested this even on a tree that doesn't have this patch. I haven't really delved deep to see why this was added earlier -- the commit log only says very little. Plus my testing with the current tree works fine so I'm happy to mention these things in the commit log. Amit