On Wed, Feb 04, 2009 at 11:37:14AM +0300, Michael Tokarev wrote:
> Marcelo Tosatti wrote:
> > On Tue, Feb 03, 2009 at 08:41:14AM +0000, Mark Marshall wrote:
> []
> > Right. I don't understand the point of converting to an "internal"
> > representation of TIOCM control bits.
>
> <fun mode>
> Well, the same goes for the IOCTL values themselves too -- like
> this CHR_IOCTL_SERIAL_SET_TIOCM itself. I mean, TIOCMSET is
> the right name for it ;) But see below.
>
> > CHR_IOCTL_SERIAL_SET_TIOCM is clearly broken as mentioned. It should at
> > least preserve the bits it does not control.
> >
> > diff --git a/qemu/qemu-char.c b/qemu/qemu-char.c
> > index ac431c7..66971e1 100644
> > --- a/qemu/qemu-char.c
> > +++ b/qemu/qemu-char.c
> > @@ -1063,33 +1063,12 @@ static int tty_serial_ioctl(CharDriverState *chr, int cmd, void *arg)
> > break;
> > case CHR_IOCTL_SERIAL_GET_TIOCM:
> > {
> > + ioctl(s->fd_in, TIOCMGET, arg);
> > }
> > break;
>
> And those parens too, let it die, die! ;)
Kill it!
> </fun mode>
>
> Other than that, an.. excellent idea, I wanted to propose
> just that when I first saw all this stuff, but was somewhat
> afraid. And I *think* there's at least *some* sense. Qemu
> is a CPU emulator and may work on another arch where those
> bits are defined differently. Maybe that was the reason for
> all this converting - to be safe than sorry, so to say. No?
Probably, yes.
Does it work for you?
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
