From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [PATCH] [UPDATE]  secondary consoles in minos
Date: Tue, 16 Jun 2009 17:07:37 +0100
Message-ID: <4A37C349.6020101@eu.citrix.com>
References: <4A37BC8D.8020703@eu.citrix.com>
	<20090616155046.GS5866@const.bordeaux.inria.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <20090616155046.GS5866@const.bordeaux.inria.fr>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, xen-devel <xen-devel@lists.xensource.com>
List-Id: xen-devel@lists.xenproject.org

Samuel Thibault wrote:

> Stefano Stabellini, le Tue 16 Jun 2009 16:38:53 +0100, a =C3=A9crit :
>> +struct consfront_dev *init_consfront(char *_nodename)
>> +{
>> +    static int consfrontends =3D 1;
>> +
>> +    if (!_nodename)
>> +        snprintf(nodename, sizeof(nodename), "device/console/%d", con=
sfrontends);
>> +    else
>> +        strncpy(nodename, _nodename, sizeof(nodename));
> [...]
>> +
>> +int openpty(void)
>> +{
>> +    struct consfront_dev *dev;
>> +
>> +    dev =3D init_consfront(NULL);
>> +    dev->fd =3D alloc_fd(FTYPE_CONSOLE);
>> +    files[dev->fd].cons.dev =3D dev;
>=20
> Mmm, what would it be used for?  It is a bit odd this way, as the
> standard openpty function does not work this way (it _creates_ the pty
> and returns the master part of the pty too, not only the slave part).
> I would have rather seen a mere addition to the open() function for a
> special path, as is done for LOG_PATH.
>=20

In qemu there is a differnt qemu_chr_open_pty per architecture so I have
implemented a stubdom specific qemu_chr_open_pty that uses openpty(void).

I chose to create a new function called openpty because it is
conceptually similar to the standard openpty, however I didn't want it
to be standard compliant because it is not the same.

I realize it can be a little confusing, but I don't think that using
another special case in the open() is much better.

Keir which one do you prefer?