All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <amc96@srcf.net>
To: Juergen Gross <jgross@suse.com>, xen-devel@lists.xenproject.org
Cc: Wei Liu <wl@xen.org>, Anthony PERARD <anthony.perard@citrix.com>
Subject: Re: [PATCH v2 1/3] tools/libs/evtchn: decouple more from mini-os
Date: Tue, 11 Jan 2022 19:56:52 +0000	[thread overview]
Message-ID: <a73bd0c2-44ee-c984-9c72-15d36afc8aa5@srcf.net> (raw)
In-Reply-To: <20220111150318.22570-2-jgross@suse.com>

On 11/01/2022 15:03, Juergen Gross wrote:
> diff --git a/tools/libs/evtchn/minios.c b/tools/libs/evtchn/minios.c
> index e5dfdc5ef5..c3a5ce3b98 100644
> --- a/tools/libs/evtchn/minios.c
> +++ b/tools/libs/evtchn/minios.c
> @@ -38,29 +38,40 @@
>  
>  #include "private.h"
>  
> -extern void minios_evtchn_close_fd(int fd);
> +LIST_HEAD(port_list, port_info);
> +
> +struct port_info {
> +    LIST_ENTRY(port_info) list;
> +    evtchn_port_t port;
> +    bool pending;
> +    bool bound;
> +};
>  
>  extern struct wait_queue_head event_queue;

Yuck.  This should come from minios's evtchn header, rather than being
extern'd like this, but lets consider that future cleanup work.

> +int minios_evtchn_close_fd(int fd);

You don't need this forward declaration, because nothing in this file
calls minios_evtchn_close_fd().  The extern should simply be deleted,
and it removes a hunk from your later xen.git series.

> @@ -69,18 +80,54 @@ static void port_dealloc(struct evtchn_port_info *port_info)
>      free(port_info);
>  }
>  
> +int minios_evtchn_close_fd(int fd)
> +{
> +    struct port_info *port_info, *tmp;
> +    struct file *file = get_file_from_fd(fd);
> +    struct port_list *port_list = file->dev;

Looking at this, the file_ops don't need to have the C ABI.

The single caller already needs access to the file structure, so could
pass both file and fd in to the ops->close() function.  Thoughts?

> +
> +    LIST_FOREACH_SAFE(port_info, port_list, list, tmp)
> +        port_dealloc(port_info);
> +    free(port_list);
> +
> +    return 0;
> +}
> +
> +static struct file_ops evtchn_ops = {

This wants to become const, when alloc_file_type() has been
appropriately const'd.

> +    .name = "evtchn",
> +    .close = minios_evtchn_close_fd,
> +    .select_rd = select_read_flag,
> +};
> +
>  /*
>   * XENEVTCHN_NO_CLOEXEC is being ignored, as there is no exec() call supported
>   * in Mini-OS.
>   */
>  int osdep_evtchn_open(xenevtchn_handle *xce, unsigned int flags)
>  {
> -    int fd = alloc_fd(FTYPE_EVTCHN);
> +    int fd;
> +    struct file *file;
> +    struct port_list *list;
> +    static unsigned int ftype_evtchn;
>  
> -    if ( fd == -1 )
> +    if ( !ftype_evtchn )
> +        ftype_evtchn = alloc_file_type(&evtchn_ops);

Hmm.  MiniOS doesn't appear to support __attribute__((constructor)) but
this would be an ideal candidate.

It would remove a non-threadsafe singleton from a (largely unrelated)
codepath.

Should be very simple to add to MiniOS.  See Xen's init_constructors(),
and add CONSTRUCTORS to the linker file.

> @@ -134,42 +171,43 @@ int xenevtchn_notify(xenevtchn_handle *xce, evtchn_port_t port)
>  
>  static void evtchn_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
>  {
> -    int fd = (int)(intptr_t)data;
> -    struct evtchn_port_info *port_info;
> +    xenevtchn_handle *xce = data;
> +    struct file *file = get_file_from_fd(xce->fd);
> +    struct port_info *port_info;
> +    struct port_list *port_list;
>  
> -    assert(files[fd].type == FTYPE_EVTCHN);
> +    assert(file);
> +    port_list = file->dev;
>      mask_evtchn(port);
> -    LIST_FOREACH(port_info, &files[fd].evtchn.ports, list)
> +    LIST_FOREACH(port_info, port_list, list)
>      {
>          if ( port_info->port == port )
>              goto found;
>      }
>  
> -    printk("Unknown port for handle %d\n", fd);
> +    printk("Unknown port for handle %d\n", xce->fd);

As you're editing this line anyway, it really wants to become "Unknown
port %d for handle %d\n".

~Andrew


  reply	other threads:[~2022-01-11 19:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-11 15:03 [PATCH v2 0/3] tools/libs: decouple more from mini-os Juergen Gross
2022-01-11 15:03 ` [PATCH v2 1/3] tools/libs/evtchn: " Juergen Gross
2022-01-11 19:56   ` Andrew Cooper [this message]
2022-01-12  7:22     ` Juergen Gross
2022-01-12 13:21       ` Juergen Gross
2022-01-11 15:03 ` [PATCH v2 2/3] tools/libs/gnttab: " Juergen Gross
2022-01-11 20:08   ` Andrew Cooper
2022-01-12  7:27     ` Juergen Gross
2022-01-12  8:34       ` Andrew Cooper
2022-01-11 15:03 ` [PATCH v2 3/3] tools/libs/ctrl: remove file related handling Juergen Gross
2022-01-11 20:10   ` Andrew Cooper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a73bd0c2-44ee-c984-9c72-15d36afc8aa5@srcf.net \
    --to=amc96@srcf.net \
    --cc=anthony.perard@citrix.com \
    --cc=jgross@suse.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.