Stefano Stabellini
2009-Jun-16 15:38 UTC
[Xen-devel] [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
Samuel Thibault
2009-Jun-16 15:50 UTC
Re: [Xen-devel] [PATCH] [UPDATE] secondary consoles in minos
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
Stefano Stabellini
2009-Jun-16 16:07 UTC
Re: [Xen-devel] [PATCH] [UPDATE] secondary consoles in minos
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