[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170623093901.ojegth5oeaabx4hs@dhcp-3-128.uk.xensource.com>
Date: Fri, 23 Jun 2017 10:39:01 +0100
From: Roger Pau Monné <roger.pau@...rix.com>
To: Stefano Stabellini <sstabellini@...nel.org>
CC: <xen-devel@...ts.xen.org>, <jgross@...e.com>,
Stefano Stabellini <stefano@...reto.com>,
<boris.ostrovsky@...cle.com>, <linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] [PATCH v4 07/18] xen/pvcalls: implement socket
command
On Thu, Jun 22, 2017 at 11:29:44AM -0700, Stefano Stabellini wrote:
> On Thu, 22 Jun 2017, Roger Pau Monné wrote:
> > On Wed, Jun 21, 2017 at 01:16:56PM -0700, Stefano Stabellini wrote:
> > > On Tue, 20 Jun 2017, Roger Pau Monné wrote:
> > > > On Thu, Jun 15, 2017 at 12:09:36PM -0700, Stefano Stabellini wrote:
> > > > > Just reply with success to the other end for now. Delay the allocation
> > > > > of the actual socket to bind and/or connect.
> > > > >
> > > > > Signed-off-by: Stefano Stabellini <stefano@...reto.com>
> > > > > CC: boris.ostrovsky@...cle.com
> > > > > CC: jgross@...e.com
> > > > > ---
> > > > > drivers/xen/pvcalls-back.c | 27 +++++++++++++++++++++++++++
> > > > > 1 file changed, 27 insertions(+)
> > > > >
> > > > > diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
> > > > > index 437c2ad..953458b 100644
> > > > > --- a/drivers/xen/pvcalls-back.c
> > > > > +++ b/drivers/xen/pvcalls-back.c
> > > > > @@ -12,12 +12,17 @@
> > > > > * GNU General Public License for more details.
> > > > > */
> > > > >
> > > > > +#include <linux/inet.h>
> > > > > #include <linux/kthread.h>
> > > > > #include <linux/list.h>
> > > > > #include <linux/radix-tree.h>
> > > > > #include <linux/module.h>
> > > > > #include <linux/semaphore.h>
> > > > > #include <linux/wait.h>
> > > > > +#include <net/sock.h>
> > > > > +#include <net/inet_common.h>
> > > > > +#include <net/inet_connection_sock.h>
> > > > > +#include <net/request_sock.h>
> > > > >
> > > > > #include <xen/events.h>
> > > > > #include <xen/grant_table.h>
> > > > > @@ -54,6 +59,28 @@ struct pvcalls_fedata {
> > > > > static int pvcalls_back_socket(struct xenbus_device *dev,
> > > > > struct xen_pvcalls_request *req)
> > > > > {
> > > > > + struct pvcalls_fedata *fedata;
> > > > > + int ret;
> > > > > + struct xen_pvcalls_response *rsp;
> > > > > +
> > > > > + fedata = dev_get_drvdata(&dev->dev);
> > > > > +
> > > > > + if (req->u.socket.domain != AF_INET ||
> > > > > + req->u.socket.type != SOCK_STREAM ||
> > > > > + (req->u.socket.protocol != IPPROTO_IP &&
> > > > > + req->u.socket.protocol != AF_INET))
> > > > > + ret = -EAFNOSUPPORT;
> > > >
> > > > Sorry for jumping into this out of the blue, but shouldn't all the
> > > > constants used above be part of the protocol? AF_INET/SOCK_STREAM/...
> > > > are all part of POSIX, but their specific value is not defined in the
> > > > standard, hence we should have XEN_AF_INET/XEN_SOCK_STREAM/... Or am I
> > > > just missing something?
> > >
> > > The values of these constants for the pvcalls protocol are defined by
> > > docs/misc/pvcalls.markdown under "Socket families and address format".
> > >
> > > They happen to be the same as the ones defined by Linux as AF_INET,
> > > SOCK_STREAM, etc, so in Linux I am just using those, but that is just an
> > > implementation detail internal to the Linux kernel driver. What is
> > > important from the protocol ABI perspective are the values defined by
> > > docs/misc/pvcalls.markdown.
> >
> > Oh I see. I still think this should be part of the public pvcalls.h
> > header, and that the error codes should be the ones defined in
> > public/errno.h (or else also added to the pvcalls header).
>
> This was done differently in the past, but now that we have a formal
> process, a person in charge of new PV drivers reviews, and design
> documents with clearly spelled out ABIs, I consider the design docs
> under docs/misc as the official specification. We don't need headers
> anymore, they are redundant. In fact, we cannot have two specifications,
> and the design docs are certainly the official ones (we don't want the
> specs to be written as header files in C). To me, the headers under
> xen/include/public/io/ are optional helpers. It doesn't matter what's in
> there, or if frontends and backends use them or not.
>
> There is really an argument for removing those headers, because they
> might get out of sync with the spec by mistake, and in those cases, then
> we really end up with two specifications for the same protocol. I would
> be in favor of `git rm'ing all files under xen/include/public/io/ for
> which we have a complete design doc under docs/misc.
Thanks for the clarification. I agree that it would be good to remove
those headers, it's confusing and it's likely that they will get out
of sync.
Roger.
Powered by blists - more mailing lists