[Qemu-devel] qemu & openpty

[Qemu-devel] qemu & openpty

[Michael Tokarev]

Hello.

One of old issues with compatibility between different
*Nix systems was the way how pty pairs were allocated.

And qemu have a twist in #includes, depending on which
platform it is run, and quite some compat cruft in
qemu-char.c about this issue.

Here it is, from qemu-char.c:

#ifdef __sun__
/* Once Solaris has openpty(), this is going to be removed. */
static int openpty(int *amaster, int *aslave, char *name,
                   struct termios *termp, struct winsize *winp)
{...}

static void cfmakeraw (struct termios *termios_p)
{...}
#endif

and later on, openpty() is used in the code.  Note that
both functions are marked as static - static to the
source file, qemu-char.c.

Now, we have ui/gtk.c, which calls openpty() and cfmakeraw()
too, but this time, there's no compat alternative implementation
provided.

Does this mean we don't need the old compat implementation
anymore?  Does gtk ui work (or at least builds) on solaris?

If gtk builds fine on solaris, it should be safe to remove
these static functions from qemu-char.c.

If not, we should obviously re-use these for ui/gtk.c --
for which I'd create a new file, say, qemu-openpty.c,
with all the system-dependent stuff inside, and create
a wrapper function, qemu_openpty(), to do the work,
and, ofcourse, remove <pty.h> and other fancy stuff
(like <stropts.h> for solaris) from qemu-common.h (!!!)
where it finally ended up.

Thanks,

/mjt

Re: [Qemu-devel] qemu & openpty

[Andreas Färber]

Am 05.06.2013 12:28, schrieb Michael Tokarev:
> Hello.
> 
> One of old issues with compatibility between different
> *Nix systems was the way how pty pairs were allocated.
> 
> And qemu have a twist in #includes, depending on which
> platform it is run, and quite some compat cruft in
> qemu-char.c about this issue.
> 
> Here it is, from qemu-char.c:
> 
> #ifdef __sun__
> /* Once Solaris has openpty(), this is going to be removed. */
> static int openpty(int *amaster, int *aslave, char *name,
>                    struct termios *termp, struct winsize *winp)
> {...}
> 
> static void cfmakeraw (struct termios *termios_p)
> {...}
> #endif
> 
> and later on, openpty() is used in the code.  Note that
> both functions are marked as static - static to the
> source file, qemu-char.c.
> 
> Now, we have ui/gtk.c, which calls openpty() and cfmakeraw()
> too, but this time, there's no compat alternative implementation
> provided.
> 
> Does this mean we don't need the old compat implementation
> anymore?  Does gtk ui work (or at least builds) on solaris?

I haven't tried yet, but this sounds like something for osdep.c, no need
for a special qemu-openpty.c.

Andreas

> 
> If gtk builds fine on solaris, it should be safe to remove
> these static functions from qemu-char.c.
> 
> If not, we should obviously re-use these for ui/gtk.c --
> for which I'd create a new file, say, qemu-openpty.c,
> with all the system-dependent stuff inside, and create
> a wrapper function, qemu_openpty(), to do the work,
> and, ofcourse, remove <pty.h> and other fancy stuff
> (like <stropts.h> for solaris) from qemu-common.h (!!!)
> where it finally ended up.
> 
> Thanks,
> 
> /mjt
> 


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] qemu & openpty

[Brad Smith]

On 05/06/13 6:28 AM, Michael Tokarev wrote:
> Hello.
>
> One of old issues with compatibility between different
> *Nix systems was the way how pty pairs were allocated.
>
> And qemu have a twist in #includes, depending on which
> platform it is run, and quite some compat cruft in
> qemu-char.c about this issue.
>
> Here it is, from qemu-char.c:
>
> #ifdef __sun__
> /* Once Solaris has openpty(), this is going to be removed. */
> static int openpty(int *amaster, int *aslave, char *name,
>                     struct termios *termp, struct winsize *winp)
> {...}
>
> static void cfmakeraw (struct termios *termios_p)
> {...}
> #endif
>
> and later on, openpty() is used in the code.  Note that
> both functions are marked as static - static to the
> source file, qemu-char.c.
>
> Now, we have ui/gtk.c, which calls openpty() and cfmakeraw()
> too, but this time, there's no compat alternative implementation
> provided.
>
> Does this mean we don't need the old compat implementation
> anymore?  Does gtk ui work (or at least builds) on solaris?
>
> If gtk builds fine on solaris, it should be safe to remove
> these static functions from qemu-char.c.
>
> If not, we should obviously re-use these for ui/gtk.c --
> for which I'd create a new file, say, qemu-openpty.c,
> with all the system-dependent stuff inside, and create
> a wrapper function, qemu_openpty(), to do the work,
> and, ofcourse, remove <pty.h> and other fancy stuff
> (like <stropts.h> for solaris) from qemu-common.h (!!!)
> where it finally ended up.
>
> Thanks,
>
> /mjt

Solaris does not have openpty() / cfmakeraw() functions so
the Gtk+ front-end is broken there as well.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [Qemu-devel] qemu & openpty

[Brad Smith]

On 05/06/13 6:28 AM, Michael Tokarev wrote:
> Hello.
>
> One of old issues with compatibility between different
> *Nix systems was the way how pty pairs were allocated.
>
> And qemu have a twist in #includes, depending on which
> platform it is run, and quite some compat cruft in
> qemu-char.c about this issue.
>
> Here it is, from qemu-char.c:
>
> #ifdef __sun__
> /* Once Solaris has openpty(), this is going to be removed. */
> static int openpty(int *amaster, int *aslave, char *name,
>                     struct termios *termp, struct winsize *winp)
> {...}
>
> static void cfmakeraw (struct termios *termios_p)
> {...}
> #endif
>
> and later on, openpty() is used in the code.  Note that
> both functions are marked as static - static to the
> source file, qemu-char.c.
>
> Now, we have ui/gtk.c, which calls openpty() and cfmakeraw()
> too, but this time, there's no compat alternative implementation
> provided.
>
> Does this mean we don't need the old compat implementation
> anymore?  Does gtk ui work (or at least builds) on solaris?
>
> If gtk builds fine on solaris, it should be safe to remove
> these static functions from qemu-char.c.
>
> If not, we should obviously re-use these for ui/gtk.c --
> for which I'd create a new file, say, qemu-openpty.c,
> with all the system-dependent stuff inside, and create
> a wrapper function, qemu_openpty(), to do the work,
> and, ofcourse, remove <pty.h> and other fancy stuff
> (like <stropts.h> for solaris) from qemu-common.h (!!!)
> where it finally ended up.
>
> Thanks,
>
> /mjt

Solaris does not have openpty() / cfmakeraw() functions so
the Gtk+ front-end is broken there as well.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [Qemu-devel] qemu & openpty

[Brad Smith]

On 05/06/13 6:28 AM, Michael Tokarev wrote:
> Hello.
>
> One of old issues with compatibility between different
> *Nix systems was the way how pty pairs were allocated.
>
> And qemu have a twist in #includes, depending on which
> platform it is run, and quite some compat cruft in
> qemu-char.c about this issue.
>
> Here it is, from qemu-char.c:
>
> #ifdef __sun__
> /* Once Solaris has openpty(), this is going to be removed. */
> static int openpty(int *amaster, int *aslave, char *name,
>                     struct termios *termp, struct winsize *winp)
> {...}
>
> static void cfmakeraw (struct termios *termios_p)
> {...}
> #endif
>
> and later on, openpty() is used in the code.  Note that
> both functions are marked as static - static to the
> source file, qemu-char.c.
>
> Now, we have ui/gtk.c, which calls openpty() and cfmakeraw()
> too, but this time, there's no compat alternative implementation
> provided.
>
> Does this mean we don't need the old compat implementation
> anymore?  Does gtk ui work (or at least builds) on solaris?
>
> If gtk builds fine on solaris, it should be safe to remove
> these static functions from qemu-char.c.
>
> If not, we should obviously re-use these for ui/gtk.c --
> for which I'd create a new file, say, qemu-openpty.c,
> with all the system-dependent stuff inside, and create
> a wrapper function, qemu_openpty(), to do the work,
> and, ofcourse, remove <pty.h> and other fancy stuff
> (like <stropts.h> for solaris) from qemu-common.h (!!!)
> where it finally ended up.
>
> Thanks,
>
> /mjt

Solaris does not have openpty() / cfmakeraw() functions so
the Gtk+ front-end is broken there as well.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [Qemu-devel] qemu & openpty

[Anthony Liguori]

Michael Tokarev <mjt@tls.msk.ru> writes:

> Hello.
>
> One of old issues with compatibility between different
> *Nix systems was the way how pty pairs were allocated.
>
> And qemu have a twist in #includes, depending on which
> platform it is run, and quite some compat cruft in
> qemu-char.c about this issue.
>
> Here it is, from qemu-char.c:
>
> #ifdef __sun__
> /* Once Solaris has openpty(), this is going to be removed. */
> static int openpty(int *amaster, int *aslave, char *name,
>                    struct termios *termp, struct winsize *winp)
> {...}
>
> static void cfmakeraw (struct termios *termios_p)
> {...}
> #endif

This code is gross.

> and later on, openpty() is used in the code.  Note that
> both functions are marked as static - static to the
> source file, qemu-char.c.
>
> Now, we have ui/gtk.c, which calls openpty() and cfmakeraw()
> too, but this time, there's no compat alternative implementation
> provided.
>
> Does this mean we don't need the old compat implementation
> anymore?  Does gtk ui work (or at least builds) on solaris?

I didn't carry this code over to the GTK UI because 1) I have no way to
test it 2) it adds a lot of complexity for something that may be used by
noone.

> If gtk builds fine on solaris, it should be safe to remove
> these static functions from qemu-char.c.

I think we're quickly getting to a point where we should simply state
that in order for any OS to be "supported" by QEMU, there must be a
buildbot.  Otherwise the testing burden is too high.

I'll send a top-level note with such a proposal.

Regards,

Anthony Liguori

> If not, we should obviously re-use these for ui/gtk.c --
> for which I'd create a new file, say, qemu-openpty.c,
> with all the system-dependent stuff inside, and create
> a wrapper function, qemu_openpty(), to do the work,
> and, ofcourse, remove <pty.h> and other fancy stuff
> (like <stropts.h> for solaris) from qemu-common.h (!!!)
> where it finally ended up.
>
> Thanks,
>
> /mjt

Re: [Qemu-devel] qemu & openpty

[Michael Tokarev]

05.06.2013 15:23, Andreas Färber wrote:
> Am 05.06.2013 12:28, schrieb Michael Tokarev:
[qemu_openpty() wrapper]

> I haven't tried yet, but this sounds like something for osdep.c, no need
> for a special qemu-openpty.c.

This is a bit more tricky.  At least on glibc, openpty() is in -lutil,
but -lutil isn't linked to, say, qemu-img.  Um-ho ;)

/mjt