Xen devel - Jun 2009 - [PATCH] [UPDATE] secondary consoles in minos

Hi all,
this is an updated version of the patch "secondary consoles in minos"
that didn''t apply cleanly the first time.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


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

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.

Samuel

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

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@lists.xensource.com
http://lists.xensource.com/xen-devel