* [PATCH v3 0/3] new ring macros, 9pfs and pvcalls headers
@ 2017-03-21 22:19 Stefano Stabellini
2017-03-21 22:19 ` [PATCH v3 1/3] ring.h: introduce macros to handle monodirectional rings with multiple req sizes Stefano Stabellini
0 siblings, 1 reply; 8+ messages in thread
From: Stefano Stabellini @ 2017-03-21 22:19 UTC (permalink / raw)
To: xen-devel; +Cc: sstabellini
Hi all,
this patch series introduces a set of new ring macros to support rings
in the formats specified by the Xen 9pfs transport and PV Calls
protocol. It also introduces the Xen 9pfs and PV Calls protocols
headers.
Changes in v3:
- fix commit message
- add newlines after read/write_packet functions
- reorder DEFINE_XEN_FLEX_RING_AND_INTF and DEFINE_XEN_FLEX_RING
Changes in v2:
- replace __attribute__((packed)) with #pragma pack
- remove XEN_9PFS_RING_ORDER, the 9pfs ring order should be dynamic
- add editor configuration blocks
- add links to the specs
Stefano Stabellini (3):
ring.h: introduce macros to handle monodirectional rings with multiple req sizes
Introduce the Xen 9pfs transport header
Introduce the pvcalls header
xen/include/public/io/9pfs.h | 57 +++++++++++++++
xen/include/public/io/pvcalls.h | 152 ++++++++++++++++++++++++++++++++++++++++
xen/include/public/io/ring.h | 133 +++++++++++++++++++++++++++++++++++
3 files changed, 342 insertions(+)
create mode 100644 xen/include/public/io/9pfs.h
create mode 100644 xen/include/public/io/pvcalls.h
Cheers,
Stefano
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 8+ messages in thread* [PATCH v3 1/3] ring.h: introduce macros to handle monodirectional rings with multiple req sizes 2017-03-21 22:19 [PATCH v3 0/3] new ring macros, 9pfs and pvcalls headers Stefano Stabellini @ 2017-03-21 22:19 ` Stefano Stabellini 2017-03-21 22:19 ` [PATCH v3 2/3] Introduce the Xen 9pfs transport header Stefano Stabellini ` (2 more replies) 0 siblings, 3 replies; 8+ messages in thread From: Stefano Stabellini @ 2017-03-21 22:19 UTC (permalink / raw) To: xen-devel; +Cc: Stefano Stabellini, sstabellini This patch introduces macros, structs and functions to handle rings in the format described by docs/misc/pvcalls.markdown and docs/misc/9pfs.markdown. The index page (struct __name##_data_intf) contains the indexes and the grant refs to setup two rings. Indexes page +----------------------+ |@0 $NAME_data_intf: | |@76: ring_order = 1 | |@80: ref[0]+ | |@84: ref[1]+ | | | | | | | +----------------------+ | v (data ring) +-------+-----------+ | @0->4095: in | | ref[0] | |-------------------| | @4096->8191: out | | ref[1] | +-------------------+ $NAME_read_packet and $NAME_write_packet are provided to read or write any data struct from/to the ring. In pvcalls, they are unused. In xen 9pfs, they are used to read or write the 9pfs header. In other protocols they could be used to read/write the whole request structure. See docs/misc/9pfs.markdown:Ring Usage to learn how to check how much data is on the ring, and how to handle notifications. There is a ring_size parameter to most functions so that protocols using these macros don't have to have a statically defined ring order at build time. In pvcalls for example, each new ring could have a different order. These macros don't help you share the indexes page or the event channels needed for notifications. You can do that with other out of band mechanisms, such as xenstore or another ring. It is not possible to use a macro to define another macro with a variable name. For this reason, this patch introduces static inline functions instead, that are not C89 compliant. Additionally, the macro defines a struct with a variable sized array, which is also not C89 compliant. Signed-off-by: Stefano Stabellini <stefano@aporeto.com> CC: konrad.wilk@oracle.com --- xen/include/public/io/ring.h | 133 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 133 insertions(+) diff --git a/xen/include/public/io/ring.h b/xen/include/public/io/ring.h index 801c0da..66f5555 100644 --- a/xen/include/public/io/ring.h +++ b/xen/include/public/io/ring.h @@ -313,6 +313,139 @@ typedef struct __name##_back_ring __name##_back_ring_t (_work_to_do) = RING_HAS_UNCONSUMED_RESPONSES(_r); \ } while (0) + +/* + * DEFINE_XEN_FLEX_RING_AND_INTF defines two monodirectional rings and + * functions to check if there is data on the ring, and to read and + * write to them. + * + * DEFINE_XEN_FLEX_RING is similar to DEFINE_XEN_FLEX_RING_AND_INTF, but + * does not define the indexes page. As different protocols can have + * extensions to the basic format, this macro allow them to define their + * own struct. + * + * XEN_FLEX_RING_SIZE + * Convenience macro to calculate the size of one of the two rings + * from the overall order. + * + * $NAME_mask + * Function to apply the size mask to an index, to reduce the index + * within the range [0-size]. + * + * $NAME_read_packet + * Function to read data from the ring. The amount of data to read is + * specified by the "size" argument. + * + * $NAME_write_packet + * Function to write data to the ring. The amount of data to write is + * specified by the "size" argument. + * + * $NAME_get_ring_ptr + * Convenience function that returns a pointer to read/write to the + * ring at the right location. + * + * $NAME_data_intf + * Indexes page, shared between frontend and backend. It also + * contains the array of grant refs. + * + * $NAME_queued + * Function to calculate how many bytes are currently on the ring, + * ready to be read. It can also be used to calculate how much free + * space is currently on the ring (ring_size - $NAME_queued()). + */ +#define XEN_FLEX_RING_SIZE(order) \ + (1UL << (order + PAGE_SHIFT - 1)) + +#define DEFINE_XEN_FLEX_RING(name) \ +static inline RING_IDX name##_mask(RING_IDX idx, RING_IDX ring_size) \ +{ \ + return (idx & (ring_size - 1)); \ +} \ + \ +static inline RING_IDX name##_mask_order(RING_IDX idx, RING_IDX ring_order) \ +{ \ + return (idx & (XEN_FLEX_RING_SIZE(ring_order) - 1)); \ +} \ + \ +static inline unsigned char* name##_get_ring_ptr(unsigned char *buf, \ + RING_IDX idx, \ + RING_IDX ring_order) \ +{ \ + return buf + name##_mask_order(idx, ring_order); \ +} \ + \ +static inline void name##_read_packet(const unsigned char *buf, \ + RING_IDX masked_prod, RING_IDX *masked_cons, \ + RING_IDX ring_size, void *opaque, size_t size) \ +{ \ + if (*masked_cons < masked_prod || \ + size <= ring_size - *masked_cons) { \ + memcpy(opaque, buf + *masked_cons, size); \ + } else { \ + memcpy(opaque, buf + *masked_cons, ring_size - *masked_cons); \ + memcpy((unsigned char *)opaque + ring_size - *masked_cons, buf, \ + size - (ring_size - *masked_cons)); \ + } \ + *masked_cons = name##_mask(*masked_cons + size, ring_size); \ +} \ + \ +static inline void name##_write_packet(unsigned char *buf, \ + RING_IDX *masked_prod, RING_IDX masked_cons, \ + RING_IDX ring_size, const void *opaque, size_t size) \ +{ \ + if (*masked_prod < masked_cons || \ + size <= ring_size - *masked_prod) { \ + memcpy(buf + *masked_prod, opaque, size); \ + } else { \ + memcpy(buf + *masked_prod, opaque, ring_size - *masked_prod); \ + memcpy(buf, (unsigned char *)opaque + (ring_size - *masked_prod), \ + size - (ring_size - *masked_prod)); \ + } \ + *masked_prod = name##_mask(*masked_prod + size, ring_size); \ +} \ + \ +struct name##_data { \ + unsigned char *in; /* half of the allocation */ \ + unsigned char *out; /* half of the allocation */ \ +}; \ + \ + \ +static inline RING_IDX name##_queued(RING_IDX prod, \ + RING_IDX cons, RING_IDX ring_size) \ +{ \ + RING_IDX size; \ + \ + if (prod == cons) \ + return 0; \ + \ + prod = name##_mask(prod, ring_size); \ + cons = name##_mask(cons, ring_size); \ + \ + if (prod == cons) \ + return ring_size; \ + \ + if (prod > cons) \ + size = prod - cons; \ + else \ + size = ring_size - (cons - prod); \ + return size; \ +}; + +#define DEFINE_XEN_FLEX_RING_AND_INTF(name) \ +struct name##_data_intf { \ + RING_IDX in_cons, in_prod; \ + \ + uint8_t pad1[56]; \ + \ + RING_IDX out_cons, out_prod; \ + \ + uint8_t pad2[56]; \ + \ + RING_IDX ring_order; \ + grant_ref_t ref[]; \ +}; \ +DEFINE_XEN_FLEX_RING(name); + #endif /* __XEN_PUBLIC_IO_RING_H__ */ /* -- 1.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH v3 2/3] Introduce the Xen 9pfs transport header 2017-03-21 22:19 ` [PATCH v3 1/3] ring.h: introduce macros to handle monodirectional rings with multiple req sizes Stefano Stabellini @ 2017-03-21 22:19 ` Stefano Stabellini 2017-03-21 22:19 ` [PATCH v3 3/3] Introduce the pvcalls header Stefano Stabellini 2017-03-23 20:58 ` [PATCH v3 1/3] ring.h: introduce macros to handle monodirectional rings with multiple req sizes Stefano Stabellini 2 siblings, 0 replies; 8+ messages in thread From: Stefano Stabellini @ 2017-03-21 22:19 UTC (permalink / raw) To: xen-devel; +Cc: Stefano Stabellini, sstabellini Define the ring according to the protocol specification, using the new DEFINE_XEN_FLEX_RING_AND_INTF macro. Signed-off-by: Stefano Stabellini <stefano@aporeto.com> CC: konrad.wilk@oracle.com --- xen/include/public/io/9pfs.h | 57 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+) create mode 100644 xen/include/public/io/9pfs.h diff --git a/xen/include/public/io/9pfs.h b/xen/include/public/io/9pfs.h new file mode 100644 index 0000000..bff9ad8 --- /dev/null +++ b/xen/include/public/io/9pfs.h @@ -0,0 +1,57 @@ +/* + * 9pfs.h -- Xen 9PFS transport + * + * Refer to docs/misc/9pfs.markdown for the specification + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to + * deal in the Software without restriction, including without limitation the + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + * + * Copyright (C) 2017 Stefano Stabellini <stefano@aporeto.com> + */ + +#ifndef __XEN_PUBLIC_IO_9PFS_H__ +#define __XEN_PUBLIC_IO_9PFS_H__ + +#include "ring.h" + +/* + * See docs/misc/9pfs.markdown in xen.git for the full specification: + * https://xenbits.xen.org/docs/unstable/misc/9pfs.html + */ +#pragma pack(push) +#pragma pack(1) +struct xen_9pfs_header { + uint32_t size; + uint8_t id; + uint16_t tag; +}; +#pragma pack(pop) + +DEFINE_XEN_FLEX_RING_AND_INTF(xen_9pfs); + +#endif + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ -- 1.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH v3 3/3] Introduce the pvcalls header 2017-03-21 22:19 ` [PATCH v3 1/3] ring.h: introduce macros to handle monodirectional rings with multiple req sizes Stefano Stabellini 2017-03-21 22:19 ` [PATCH v3 2/3] Introduce the Xen 9pfs transport header Stefano Stabellini @ 2017-03-21 22:19 ` Stefano Stabellini 2017-03-23 20:58 ` [PATCH v3 1/3] ring.h: introduce macros to handle monodirectional rings with multiple req sizes Stefano Stabellini 2 siblings, 0 replies; 8+ messages in thread From: Stefano Stabellini @ 2017-03-21 22:19 UTC (permalink / raw) To: xen-devel; +Cc: Stefano Stabellini, sstabellini Define the ring and request and response structs according to the specification. Use the new DEFINE_XEN_FLEX_RING macro. Signed-off-by: Stefano Stabellini <stefano@aporeto.com> CC: konrad.wilk@oracle.com --- xen/include/public/io/pvcalls.h | 152 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 152 insertions(+) create mode 100644 xen/include/public/io/pvcalls.h diff --git a/xen/include/public/io/pvcalls.h b/xen/include/public/io/pvcalls.h new file mode 100644 index 0000000..4123528 --- /dev/null +++ b/xen/include/public/io/pvcalls.h @@ -0,0 +1,152 @@ +/* + * pvcalls.h -- Xen PV Calls Protocol + * + * Refer to docs/misc/pvcalls.markdown for the specification + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to + * deal in the Software without restriction, including without limitation the + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + * + * Copyright (C) 2017 Stefano Stabellini <stefano@aporeto.com> + */ + +#ifndef __XEN_PUBLIC_IO_PVCALLS_H__ +#define __XEN_PUBLIC_IO_PVCALLS_H__ + +#include "ring.h" + +/* + * See docs/misc/pvcalls.markdown in xen.git for the full specification: + * https://xenbits.xen.org/docs/unstable/misc/pvcalls.html + */ +struct pvcalls_data_intf { + RING_IDX in_cons, in_prod, in_error; + + uint8_t pad1[52]; + + RING_IDX out_cons, out_prod, out_error; + + uint8_t pad2[52]; + + RING_IDX ring_order; + grant_ref_t ref[]; +}; +DEFINE_XEN_FLEX_RING(pvcalls); + +#define PVCALLS_SOCKET 0 +#define PVCALLS_CONNECT 1 +#define PVCALLS_RELEASE 2 +#define PVCALLS_BIND 3 +#define PVCALLS_LISTEN 4 +#define PVCALLS_ACCEPT 5 +#define PVCALLS_POLL 6 + +struct xen_pvcalls_request { + uint32_t req_id; /* private to guest, echoed in response */ + uint32_t cmd; /* command to execute */ + union { + struct xen_pvcalls_socket { + uint64_t id; + uint32_t domain; + uint32_t type; + uint32_t protocol; + } socket; + struct xen_pvcalls_connect { + uint64_t id; + uint8_t addr[28]; + uint32_t len; + uint32_t flags; + grant_ref_t ref; + uint32_t evtchn; + } connect; + struct xen_pvcalls_release { + uint64_t id; + uint8_t reuse; + } release; + struct xen_pvcalls_bind { + uint64_t id; + uint8_t addr[28]; + uint32_t len; + } bind; + struct xen_pvcalls_listen { + uint64_t id; + uint32_t backlog; + } listen; + struct xen_pvcalls_accept { + uint64_t id; + uint64_t id_new; + grant_ref_t ref; + uint32_t evtchn; + } accept; + struct xen_pvcalls_poll { + uint64_t id; + } poll; + /* dummy member to force sizeof(struct xen_pvcalls_request) + * to match across archs */ + struct xen_pvcalls_dummy { + uint8_t dummy[56]; + } dummy; + } u; +}; + +struct xen_pvcalls_response { + uint32_t req_id; + uint32_t cmd; + int32_t ret; + uint32_t pad; + union { + struct _xen_pvcalls_socket { + uint64_t id; + } socket; + struct _xen_pvcalls_connect { + uint64_t id; + } connect; + struct _xen_pvcalls_release { + uint64_t id; + } release; + struct _xen_pvcalls_bind { + uint64_t id; + } bind; + struct _xen_pvcalls_listen { + uint64_t id; + } listen; + struct _xen_pvcalls_accept { + uint64_t id; + } accept; + struct _xen_pvcalls_poll { + uint64_t id; + } poll; + struct _xen_pvcalls_dummy { + uint8_t dummy[8]; + } dummy; + } u; +}; + +DEFINE_RING_TYPES(xen_pvcalls, struct xen_pvcalls_request, + struct xen_pvcalls_response); + +#endif + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ -- 1.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH v3 1/3] ring.h: introduce macros to handle monodirectional rings with multiple req sizes 2017-03-21 22:19 ` [PATCH v3 1/3] ring.h: introduce macros to handle monodirectional rings with multiple req sizes Stefano Stabellini 2017-03-21 22:19 ` [PATCH v3 2/3] Introduce the Xen 9pfs transport header Stefano Stabellini 2017-03-21 22:19 ` [PATCH v3 3/3] Introduce the pvcalls header Stefano Stabellini @ 2017-03-23 20:58 ` Stefano Stabellini 2017-03-23 21:48 ` Stefano Stabellini 2 siblings, 1 reply; 8+ messages in thread From: Stefano Stabellini @ 2017-03-23 20:58 UTC (permalink / raw) To: Stefano Stabellini; +Cc: Stefano Stabellini, xen-devel, jbeulich CC'ing Jan On Tue, 21 Mar 2017, Stefano Stabellini wrote: > +static inline void name##_read_packet(const unsigned char *buf, \ > + RING_IDX masked_prod, RING_IDX *masked_cons, \ > + RING_IDX ring_size, void *opaque, size_t size) \ > +{ \ > + if (*masked_cons < masked_prod || \ > + size <= ring_size - *masked_cons) { \ > + memcpy(opaque, buf + *masked_cons, size); \ > + } else { \ > + memcpy(opaque, buf + *masked_cons, ring_size - *masked_cons); \ > + memcpy((unsigned char *)opaque + ring_size - *masked_cons, buf, \ > + size - (ring_size - *masked_cons)); \ > + } \ > + *masked_cons = name##_mask(*masked_cons + size, ring_size); \ > +} \ I like these macros, they make the code that uses them very nice, look at patch #2 for example. So far, I tested them by importing them in Linux and QEMU, I didn't realize that we have an -ansi check on the public headers in Xen (see xen/include/Makefile:headers.chk). Because of the static inline functions, there is no hope to compile them with -ansi. As soon as we introduce the first user (9pfs, patch #2 of this series), the compilation will break. At the same time I am very keen on the static inlines and wouldn't want to lose them. Question 1: Should I move these useful macros elsewhere? If so, where? Maybe I could move them to the spec, for example docs/misc/9pfs.markdown. Xen doesn't really need them, it's just the frontend and backend implementations that could benefit from them. If we decide to keep them in ring.h, I guess I'll have to change the headers.chk check in xen/include/Makefile for the 9pfs and pvcalls headers to be -std=c99 (*only* for 9pfs and pvcalls, of course). Question 2: In addition to the static inlines problem, the new macros also use memcpy, that needs declaring. I could import <strings.h>, but I don't think it makes sense in a Xen public header. Instead, would you be OK with me adding the following to ring.h? #include <stddef.h> /* needed for size_t */ extern void *memcpy(void *dest, const void *src, size_t s); Of course, if we decide to move the new macros somewhere else, this problem goes away with them. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v3 1/3] ring.h: introduce macros to handle monodirectional rings with multiple req sizes 2017-03-23 20:58 ` [PATCH v3 1/3] ring.h: introduce macros to handle monodirectional rings with multiple req sizes Stefano Stabellini @ 2017-03-23 21:48 ` Stefano Stabellini 2017-03-24 7:44 ` Jan Beulich 0 siblings, 1 reply; 8+ messages in thread From: Stefano Stabellini @ 2017-03-23 21:48 UTC (permalink / raw) To: Stefano Stabellini; +Cc: Stefano Stabellini, xen-devel, jbeulich On Thu, 23 Mar 2017, Stefano Stabellini wrote: > CC'ing Jan > > On Tue, 21 Mar 2017, Stefano Stabellini wrote: > > +static inline void name##_read_packet(const unsigned char *buf, \ > > + RING_IDX masked_prod, RING_IDX *masked_cons, \ > > + RING_IDX ring_size, void *opaque, size_t size) \ > > +{ \ > > + if (*masked_cons < masked_prod || \ > > + size <= ring_size - *masked_cons) { \ > > + memcpy(opaque, buf + *masked_cons, size); \ > > + } else { \ > > + memcpy(opaque, buf + *masked_cons, ring_size - *masked_cons); \ > > + memcpy((unsigned char *)opaque + ring_size - *masked_cons, buf, \ > > + size - (ring_size - *masked_cons)); \ > > + } \ > > + *masked_cons = name##_mask(*masked_cons + size, ring_size); \ > > +} \ > > I like these macros, they make the code that uses them very nice, look > at patch #2 for example. So far, I tested them by importing them in > Linux and QEMU, I didn't realize that we have an -ansi check on the > public headers in Xen (see xen/include/Makefile:headers.chk). > > Because of the static inline functions, there is no hope to compile them > with -ansi. As soon as we introduce the first user (9pfs, patch #2 of > this series), the compilation will break. > > At the same time I am very keen on the static inlines and wouldn't want > to lose them. > > > Question 1: Should I move these useful macros elsewhere? If so, where? > Maybe I could move them to the spec, for example > docs/misc/9pfs.markdown. Xen doesn't really need them, it's just the > frontend and backend implementations that could benefit from them. > > If we decide to keep them in ring.h, I guess I'll have to change the > headers.chk check in xen/include/Makefile for the 9pfs and pvcalls > headers to be -std=c99 (*only* for 9pfs and pvcalls, of course). Actually, I noticed there is already a way to remove the ansi compliance check: I just need to add 9pfs and pvcalls to the filter-out list of PUBLIC_ANSI_HEADERS in xen/include/Makefile. Is that OK for you? > Question 2: In addition to the static inlines problem, the new macros > also use memcpy, that needs declaring. I could import <strings.h>, but I > don't think it makes sense in a Xen public header. Instead, would you > be OK with me adding the following to ring.h? > > #include <stddef.h> /* needed for size_t */ > extern void *memcpy(void *dest, const void *src, size_t s); > > Of course, if we decide to move the new macros somewhere else, this > problem goes away with them. I realized that stddef.h is not allowed either. I am not sure what to do here. If I remove the ansi check, actually these headers won't be involved in the build, so there won't be any breakages, and all users will have a memcpy defined. So maybe we could just get away without defining memcpy? Other suggestions? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v3 1/3] ring.h: introduce macros to handle monodirectional rings with multiple req sizes 2017-03-23 21:48 ` Stefano Stabellini @ 2017-03-24 7:44 ` Jan Beulich 2017-03-24 18:15 ` Stefano Stabellini 0 siblings, 1 reply; 8+ messages in thread From: Jan Beulich @ 2017-03-24 7:44 UTC (permalink / raw) To: Stefano Stabellini; +Cc: Stefano Stabellini, xen-devel >>> On 23.03.17 at 22:48, <sstabellini@kernel.org> wrote: > On Thu, 23 Mar 2017, Stefano Stabellini wrote: >> CC'ing Jan As a first remark, I'm slightly confused by this being v3 when a standalone v3 had been sent on Feb 22 already. >> On Tue, 21 Mar 2017, Stefano Stabellini wrote: >> > +static inline void name##_read_packet(const unsigned char *buf, \ >> > + RING_IDX masked_prod, RING_IDX *masked_cons, \ >> > + RING_IDX ring_size, void *opaque, size_t size) \ >> > +{ \ >> > + if (*masked_cons < masked_prod || \ >> > + size <= ring_size - *masked_cons) { \ >> > + memcpy(opaque, buf + *masked_cons, size); \ >> > + } else { \ >> > + memcpy(opaque, buf + *masked_cons, ring_size - *masked_cons); \ >> > + memcpy((unsigned char *)opaque + ring_size - *masked_cons, buf, \ >> > + size - (ring_size - *masked_cons)); \ >> > + } \ >> > + *masked_cons = name##_mask(*masked_cons + size, ring_size); \ >> > +} \ >> >> I like these macros, they make the code that uses them very nice, look >> at patch #2 for example. So far, I tested them by importing them in >> Linux and QEMU, I didn't realize that we have an -ansi check on the >> public headers in Xen (see xen/include/Makefile:headers.chk). >> >> Because of the static inline functions, there is no hope to compile them >> with -ansi. As soon as we introduce the first user (9pfs, patch #2 of >> this series), the compilation will break. >> >> At the same time I am very keen on the static inlines and wouldn't want >> to lose them. >> >> >> Question 1: Should I move these useful macros elsewhere? If so, where? >> Maybe I could move them to the spec, for example >> docs/misc/9pfs.markdown. Xen doesn't really need them, it's just the >> frontend and backend implementations that could benefit from them. >> >> If we decide to keep them in ring.h, I guess I'll have to change the >> headers.chk check in xen/include/Makefile for the 9pfs and pvcalls >> headers to be -std=c99 (*only* for 9pfs and pvcalls, of course). > > Actually, I noticed there is already a way to remove the ansi compliance > check: I just need to add 9pfs and pvcalls to the filter-out list of > PUBLIC_ANSI_HEADERS in xen/include/Makefile. Is that OK for you? I think that's acceptable. They shouldn't go entirely unchecked though, so I'd ask for adding a new C99 category, as you suggest yourself above. >> Question 2: In addition to the static inlines problem, the new macros >> also use memcpy, that needs declaring. I could import <strings.h>, but I >> don't think it makes sense in a Xen public header. Instead, would you >> be OK with me adding the following to ring.h? >> >> #include <stddef.h> /* needed for size_t */ >> extern void *memcpy(void *dest, const void *src, size_t s); >> >> Of course, if we decide to move the new macros somewhere else, this >> problem goes away with them. > > I realized that stddef.h is not allowed either. I am not sure what to do > here. If I remove the ansi check, actually these headers won't be > involved in the build, so there won't be any breakages, and all users > will have a memcpy defined. So maybe we could just get away without > defining memcpy? Other suggestions? We expect stdint.h to be included up front (or the types it declares to be made available some other way); I don't see why you shouldn't be allowed to expect the equivalent here before including these new ones. Just make sure you prominently state the prereqs (near the top of the headers, perhaps at the place where one would normally expect such #include-s), in terms of types and declarations (i.e. preferably not in terms of standard header names, because of the permitted substitutions). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v3 1/3] ring.h: introduce macros to handle monodirectional rings with multiple req sizes 2017-03-24 7:44 ` Jan Beulich @ 2017-03-24 18:15 ` Stefano Stabellini 0 siblings, 0 replies; 8+ messages in thread From: Stefano Stabellini @ 2017-03-24 18:15 UTC (permalink / raw) To: Jan Beulich; +Cc: Stefano Stabellini, xen-devel, Stefano Stabellini On Fri, 24 Mar 2017, Jan Beulich wrote: > >>> On 23.03.17 at 22:48, <sstabellini@kernel.org> wrote: > > On Thu, 23 Mar 2017, Stefano Stabellini wrote: > >> CC'ing Jan > > As a first remark, I'm slightly confused by this being v3 when a > standalone v3 had been sent on Feb 22 already. Yes, sorry, I actually sent 4 versions of this patch as standalone. However, after adding the other two patches I reset the version count. > >> On Tue, 21 Mar 2017, Stefano Stabellini wrote: > >> > +static inline void name##_read_packet(const unsigned char *buf, \ > >> > + RING_IDX masked_prod, RING_IDX *masked_cons, \ > >> > + RING_IDX ring_size, void *opaque, size_t size) \ > >> > +{ \ > >> > + if (*masked_cons < masked_prod || \ > >> > + size <= ring_size - *masked_cons) { \ > >> > + memcpy(opaque, buf + *masked_cons, size); \ > >> > + } else { \ > >> > + memcpy(opaque, buf + *masked_cons, ring_size - *masked_cons); \ > >> > + memcpy((unsigned char *)opaque + ring_size - *masked_cons, buf, \ > >> > + size - (ring_size - *masked_cons)); \ > >> > + } \ > >> > + *masked_cons = name##_mask(*masked_cons + size, ring_size); \ > >> > +} \ > >> > >> I like these macros, they make the code that uses them very nice, look > >> at patch #2 for example. So far, I tested them by importing them in > >> Linux and QEMU, I didn't realize that we have an -ansi check on the > >> public headers in Xen (see xen/include/Makefile:headers.chk). > >> > >> Because of the static inline functions, there is no hope to compile them > >> with -ansi. As soon as we introduce the first user (9pfs, patch #2 of > >> this series), the compilation will break. > >> > >> At the same time I am very keen on the static inlines and wouldn't want > >> to lose them. > >> > >> > >> Question 1: Should I move these useful macros elsewhere? If so, where? > >> Maybe I could move them to the spec, for example > >> docs/misc/9pfs.markdown. Xen doesn't really need them, it's just the > >> frontend and backend implementations that could benefit from them. > >> > >> If we decide to keep them in ring.h, I guess I'll have to change the > >> headers.chk check in xen/include/Makefile for the 9pfs and pvcalls > >> headers to be -std=c99 (*only* for 9pfs and pvcalls, of course). > > > > Actually, I noticed there is already a way to remove the ansi compliance > > check: I just need to add 9pfs and pvcalls to the filter-out list of > > PUBLIC_ANSI_HEADERS in xen/include/Makefile. Is that OK for you? > > I think that's acceptable. They shouldn't go entirely unchecked > though, so I'd ask for adding a new C99 category, as you suggest > yourself above. OK, that makes sense. > >> Question 2: In addition to the static inlines problem, the new macros > >> also use memcpy, that needs declaring. I could import <strings.h>, but I > >> don't think it makes sense in a Xen public header. Instead, would you > >> be OK with me adding the following to ring.h? > >> > >> #include <stddef.h> /* needed for size_t */ > >> extern void *memcpy(void *dest, const void *src, size_t s); > >> > >> Of course, if we decide to move the new macros somewhere else, this > >> problem goes away with them. > > > > I realized that stddef.h is not allowed either. I am not sure what to do > > here. If I remove the ansi check, actually these headers won't be > > involved in the build, so there won't be any breakages, and all users > > will have a memcpy defined. So maybe we could just get away without > > defining memcpy? Other suggestions? > > We expect stdint.h to be included up front (or the types it > declares to be made available some other way); I don't see why > you shouldn't be allowed to expect the equivalent here before > including these new ones. Just make sure you prominently state > the prereqs (near the top of the headers, perhaps at the place > where one would normally expect such #include-s), in terms of > types and declarations (i.e. preferably not in terms of standard > header names, because of the permitted substitutions). OK, that is a good suggestion, I'll do that. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-03-24 18:15 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-03-21 22:19 [PATCH v3 0/3] new ring macros, 9pfs and pvcalls headers Stefano Stabellini 2017-03-21 22:19 ` [PATCH v3 1/3] ring.h: introduce macros to handle monodirectional rings with multiple req sizes Stefano Stabellini 2017-03-21 22:19 ` [PATCH v3 2/3] Introduce the Xen 9pfs transport header Stefano Stabellini 2017-03-21 22:19 ` [PATCH v3 3/3] Introduce the pvcalls header Stefano Stabellini 2017-03-23 20:58 ` [PATCH v3 1/3] ring.h: introduce macros to handle monodirectional rings with multiple req sizes Stefano Stabellini 2017-03-23 21:48 ` Stefano Stabellini 2017-03-24 7:44 ` Jan Beulich 2017-03-24 18:15 ` Stefano Stabellini
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.