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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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