|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 10/14 v4] xen/arm: vpl011: Modify xenconsole to support multiple consoles
On Tue, 6 Jun 2017, Bhupinder Thakur wrote:
> This patch adds the support for multiple consoles and introduces the iterator
> functions to operate on multiple consoles.
>
> This patch is in preparation to support a new vuart console.
>
> Signed-off-by: Bhupinder Thakur <bhupinder.thakur@xxxxxxxxxx>
> ---
> CC: ij
> CC: wl
> CC: ss
> CC: jg
>
> Changes since v3:
> - The changes in xenconsole have been split into four patches. This is the
> third patch.
>
> tools/console/daemon/io.c | 364
> +++++++++++++++++++++++++++++++++-------------
> 1 file changed, 263 insertions(+), 101 deletions(-)
>
> diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
> index c5dd08d..db73e10 100644
> --- a/tools/console/daemon/io.c
> +++ b/tools/console/daemon/io.c
> @@ -90,12 +90,15 @@ struct buffer {
> };
>
> struct console {
> + char *xsname;
How is xsname useful? It doesn't look like it is used anywhere except
init, right?
> + char *ttyname;
> int master_fd;
> int master_pollfd_idx;
> int slave_fd;
> int log_fd;
> struct buffer buffer;
> - char *conspath;
> + char *xspath;
A simple trick to make patch easier to handle is to separate out changes
like this one: renaming conspath to xspath causes a lot of churn, which
ends up all mixed up with other meaningful changes.
> + char *log_suffix;
> int ring_ref;
> xenevtchn_port_or_error_t local_port;
> xenevtchn_port_or_error_t remote_port;
> @@ -103,6 +106,23 @@ struct console {
> struct domain *d;
> };
>
> +struct console_data {
> + char *xsname;
> + char *ttyname;
> + char *log_suffix;
> +};
> +
> +static struct console_data console_data[] = {
> +
> + {
> + .xsname = "/console",
> + .ttyname = "tty",
> + .log_suffix = "",
> + },
> +};
> +
> +#define MAX_CONSOLE (sizeof(console_data)/sizeof(struct console_data))
> +
> struct domain {
> int domid;
> bool is_dead;
> @@ -112,11 +132,90 @@ struct domain {
> int xce_pollfd_idx;
> int event_count;
> long long next_period;
> - struct console console;
> + struct console console[MAX_CONSOLE];
> };
>
> +static void buffer_append(struct console *con, unsigned int data)
> {
> struct buffer *buffer = &con->buffer;
> + struct xencons_interface *intf = con->interface;
> + xenevtchn_port_or_error_t rxport = (xenevtchn_port_or_error_t)data;
> struct domain *dom = con->d;
> XENCONS_RING_IDX cons, prod, size;
> - struct xencons_interface *intf = con->interface;
> +
> + /* If incoming data is not for the current console then ignore. */
> + if (con->local_port != rxport)
> + return;
>
> cons = intf->out_cons;
> prod = intf->out_prod;
> @@ -427,6 +541,9 @@ static int console_create_tty(struct console *con)
> struct termios term;
> struct domain *dom = con->d;
>
> + if (!console_enabled(con))
> + return 1;
Is this actually useful? It doesn't look like the rest code changed in
regards to console_create_tty.
> assert(con->slave_fd == -1);
> assert(con->master_fd == -1);
>
> @@ -594,15 +711,16 @@ static int console_create_ring(struct console *con)
>
> con->local_port = -1;
> con->remote_port = -1;
> - if (dom->xce_handle != NULL)
> - xenevtchn_close(dom->xce_handle);
>
> - /* Opening evtchn independently for each console is a bit
> - * wasteful, but that's how the code is structured... */
> - dom->xce_handle = xenevtchn_open(NULL, 0);
> - if (dom->xce_handle == NULL) {
> - err = errno;
> - goto out;
> + if (dom->xce_handle == NULL)
> + {
> + /* Opening evtchn independently for each console is a bit
> + * wasteful, but that's how the code is structured... */
> + dom->xce_handle = xenevtchn_open(NULL, 0);
> + if (dom->xce_handle == NULL) {
> + err = errno;
> + goto out;
> + }
I think we need to do this per console actually, see below
> }
>
> rc = xenevtchn_bind_interdomain(dom->xce_handle,
> @@ -1092,14 +1282,13 @@ void handle_io(void)
> if ((now+5) > d->next_period) {
> d->next_period = now + RATE_LIMIT_PERIOD;
> if (d->event_count >= RATE_LIMIT_ALLOWANCE) {
> - (void)xenevtchn_unmask(d->xce_handle,
> con->local_port);
> + console_iter_void_arg1(d,
> console_event_unmask);
> }
> d->event_count = 0;
> }
> }
> @@ -1107,28 +1296,15 @@ void handle_io(void)
> d->next_period < next_timeout)
> next_timeout = d->next_period;
> } else if (d->xce_handle != NULL) {
> - if (discard_overflowed_data ||
> - !con->buffer.max_capacity ||
> - con->buffer.size <
> con->buffer.max_capacity) {
> - int evtchn_fd =
> xenevtchn_fd(d->xce_handle);
> - d->xce_pollfd_idx = set_fds(evtchn_fd,
> -
> POLLIN|POLLPRI);
> + if (console_iter_bool_arg1(d,
> buffer_available))
> + {
> + int evtchn_fd =
> xenevtchn_fd(d->xce_handle);
> + d->xce_pollfd_idx =
> set_fds(evtchn_fd,
> +
> POLLIN|POLLPRI);
> + }
> }
Is there a reason why we have one xce_pollfd_idx, xce_handle,
next_period and event_count per domain, rather than per console?
It is strange to set xce_pollfd_idx if at least one console of the
domain has enough buffer availability. Similarly, it is strange to count
the next_period on a per domain basis, regardless of the number of
consoles. It would be natural to do it at the console level.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |