| Message ID | 1254225888-17093-2-git-send-email-amit.shah@redhat.com |
|---|---|
| State | Superseded |
| Headers | show |
Amit Shah wrote: > Notify users of the char interface whenever the file / connection is > opened. > > The existing RESET event is triggered when the qemu char state is reset > as well; which may not be as interesting as char device open events. > > Signed-off-by: Amit Shah <amit.shah@redhat.com> > This series breaks the build (ppc440_bamboo.c). You should always build without an explicit --target-list to avoid this in the future. Regards, Anthony Liguori
On (Wed) Sep 30 2009 [16:13:33], Anthony Liguori wrote: > Amit Shah wrote: >> Notify users of the char interface whenever the file / connection is >> opened. >> >> The existing RESET event is triggered when the qemu char state is reset >> as well; which may not be as interesting as char device open events. >> >> Signed-off-by: Amit Shah <amit.shah@redhat.com> >> > > This series breaks the build (ppc440_bamboo.c). This patch or this series? If it's this patch, that's surprising! > You should always build without an explicit --target-list to avoid this > in the future. Sure -- I intend to when I send a request for the merging once all the comments have been sorted out. Thanks, Amit
On (Thu) Oct 01 2009 [10:26:22], Amit Shah wrote: > On (Wed) Sep 30 2009 [16:13:33], Anthony Liguori wrote: > > Amit Shah wrote: > >> Notify users of the char interface whenever the file / connection is > >> opened. > >> > >> The existing RESET event is triggered when the qemu char state is reset > >> as well; which may not be as interesting as char device open events. > >> > >> Signed-off-by: Amit Shah <amit.shah@redhat.com> > >> > > > > This series breaks the build (ppc440_bamboo.c). > > This patch or this series? If it's this patch, that's surprising! OK; it's the other patch. This ppc440 machine also init'ed the virtio-console-pci the way pc.c did; I'll remove this as well. Amit
Amit Shah wrote: > On (Wed) Sep 30 2009 [16:13:33], Anthony Liguori wrote: > >> Amit Shah wrote: >> >>> Notify users of the char interface whenever the file / connection is >>> opened. >>> >>> The existing RESET event is triggered when the qemu char state is reset >>> as well; which may not be as interesting as char device open events. >>> >>> Signed-off-by: Amit Shah <amit.shah@redhat.com> >>> >>> >> This series breaks the build (ppc440_bamboo.c). >> > > This patch or this series? If it's this patch, that's surprising! > > >> You should always build without an explicit --target-list to avoid this >> in the future. >> > > Sure -- I intend to when I send a request for the merging once all the > comments have been sorted out. > If you don't intend a patch series to be merged, then you should put [RFC] in the subject. Regards, Anthony Liguori
On 10/01/09 14:54, Anthony Liguori wrote: >>> You should always build without an explicit --target-list to avoid >>> this in the future. >> >> Sure -- I intend to when I send a request for the merging once all the >> comments have been sorted out. > > If you don't intend a patch series to be merged, then you should put > [RFC] in the subject. Huh? I'm a bit surprised you are considering patches for merge which are discussed alot on the list and thus most likely not final. cheers, Gerd
Gerd Hoffmann wrote: > On 10/01/09 14:54, Anthony Liguori wrote: >>>> You should always build without an explicit --target-list to avoid >>>> this in the future. >>> >>> Sure -- I intend to when I send a request for the merging once all the >>> comments have been sorted out. >> >> If you don't intend a patch series to be merged, then you should put >> [RFC] in the subject. > > Huh? I'm a bit surprised you are considering patches for merge which > are discussed alot on the list and thus most likely not final. Amit has repeatedly asked me to consider these series for merging. If there is no indicator in the subject that they are not intended to be merged, then they're going to go through staging. I'll remove them from staging once I see that the patches are contended. The reason I do this is to make sure that patches don't get dropped. There's no excuse for a patch to be on the mailing list that isn't properly tested (especially build tested) without an appropriate tag indicating that like [RFC]. Regards, Anthony Liguori > cheers, > Gerd
On 10/01/09 15:48, Anthony Liguori wrote: > I'll remove them from staging once I see that the patches are contended. > The reason I do this is to make sure that patches don't get dropped. Stick everything into the staging queue, solve conflicts, just to throw them out again later (which might produce conflicts again) doesn't look like a good workflow to me. You spend time solving patch conflicts for nothing. There must be better ways to keep track of the patches ... > There's no excuse for a patch to be on the mailing list that isn't > properly tested (especially build tested) without an appropriate tag > indicating that like [RFC]. Indeed. cheers, Gerd
diff --git a/qemu-char.c b/qemu-char.c index 8084a67..e7d091c 100644 --- a/qemu-char.c +++ b/qemu-char.c @@ -479,6 +479,8 @@ static CharDriverState *qemu_chr_open_mux(CharDriverState *drv) chr->chr_write = mux_chr_write; chr->chr_update_read_handler = mux_chr_update_read_handler; chr->chr_accept_input = mux_chr_accept_input; + + qemu_chr_event(chr, CHR_EVENT_OPENED); return chr; } @@ -627,6 +629,7 @@ static CharDriverState *qemu_chr_open_fd(int fd_in, int fd_out) chr->chr_close = fd_chr_close; qemu_chr_reset(chr); + qemu_chr_event(chr, CHR_EVENT_OPENED); return chr; } @@ -925,8 +928,10 @@ static void pty_chr_state(CharDriverState *chr, int connected) * the virtual device linked to our pty. */ qemu_mod_timer(s->timer, qemu_get_clock(rt_clock) + 1000); } else { - if (!s->connected) + if (!s->connected) { qemu_chr_reset(chr); + qemu_chr_event(chr, CHR_EVENT_OPENED); + } s->connected = 1; } } @@ -1166,6 +1171,7 @@ static CharDriverState *qemu_chr_open_tty(QemuOpts *opts) } chr->chr_ioctl = tty_serial_ioctl; qemu_chr_reset(chr); + qemu_chr_event(chr, CHR_EVENT_OPENED); return chr; } #else /* ! __linux__ && ! __sun__ */ @@ -1312,6 +1318,7 @@ static CharDriverState *qemu_chr_open_pp(QemuOpts *opts) chr->opaque = drv; qemu_chr_reset(chr); + qemu_chr_event(chr, CHR_EVENT_OPENED); return chr; } @@ -1593,6 +1600,7 @@ static CharDriverState *qemu_chr_open_win(QemuOpts *opts) return NULL; } qemu_chr_reset(chr); + qemu_chr_event(chr, CHR_EVENT_OPENED); return chr; } @@ -1693,6 +1701,7 @@ static CharDriverState *qemu_chr_open_win_pipe(QemuOpts *opts) return NULL; } qemu_chr_reset(chr); + qemu_chr_event(chr, CHR_EVENT_OPENED); return chr; } @@ -1707,6 +1716,7 @@ static CharDriverState *qemu_chr_open_win_file(HANDLE fd_out) chr->opaque = s; chr->chr_write = win_chr_write; qemu_chr_reset(chr); + qemu_chr_event(chr, CHR_EVENT_OPENED); return chr; } @@ -1828,6 +1838,7 @@ static CharDriverState *qemu_chr_open_udp(QemuOpts *opts) chr->chr_write = udp_chr_write; chr->chr_update_read_handler = udp_chr_update_read_handler; chr->chr_close = udp_chr_close; + qemu_chr_event(chr, CHR_EVENT_OPENED); return chr; return_err: @@ -2034,6 +2045,7 @@ static void tcp_chr_connect(void *opaque) qemu_set_fd_handler2(s->fd, tcp_chr_read_poll, tcp_chr_read, NULL, chr); qemu_chr_reset(chr); + qemu_chr_event(chr, CHR_EVENT_OPENED); } #define IACSET(x,a,b,c) x[0] = a; x[1] = b; x[2] = c; diff --git a/qemu-char.h b/qemu-char.h index c0654bc..43e61e0 100644 --- a/qemu-char.h +++ b/qemu-char.h @@ -14,6 +14,7 @@ #define CHR_EVENT_MUX_IN 3 /* mux-focus was set to this terminal */ #define CHR_EVENT_MUX_OUT 4 /* mux-focus will move on */ #define CHR_EVENT_CLOSED 5 /* connection closed */ +#define CHR_EVENT_OPENED 6 /* connection opened */ #define CHR_IOCTL_SERIAL_SET_PARAMS 1
Notify users of the char interface whenever the file / connection is opened. The existing RESET event is triggered when the qemu char state is reset as well; which may not be as interesting as char device open events. Signed-off-by: Amit Shah <amit.shah@redhat.com> --- qemu-char.c | 14 +++++++++++++- qemu-char.h | 1 + 2 files changed, 14 insertions(+), 1 deletions(-)