WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] [UPDATE] secondary consoles in minos

To: Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] [UPDATE] secondary consoles in minos
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Tue, 16 Jun 2009 17:07:37 +0100
Cc:
Delivery-date: Tue, 16 Jun 2009 09:03:49 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20090616155046.GS5866@xxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4A37BC8D.8020703@xxxxxxxxxxxxx> <20090616155046.GS5866@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.14 (X11/20080505)
Samuel Thibault wrote:

> Stefano Stabellini, le Tue 16 Jun 2009 16:38:53 +0100, a écrit :
>> +struct consfront_dev *init_consfront(char *_nodename)
>> +{
>> +    static int consfrontends = 1;
>> +
>> +    if (!_nodename)
>> +        snprintf(nodename, sizeof(nodename), "device/console/%d", 
>> consfrontends);
>> +    else
>> +        strncpy(nodename, _nodename, sizeof(nodename));
> [...]
>> +
>> +int openpty(void)
>> +{
>> +    struct consfront_dev *dev;
>> +
>> +    dev = init_consfront(NULL);
>> +    dev->fd = alloc_fd(FTYPE_CONSOLE);
>> +    files[dev->fd].cons.dev = dev;
> 
> 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.
> 

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?


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>