similar to: [RFC] UAPI: Check headers by compiling all together as C++

Here's a set of patches that inserts a step into the build process to make sure that the UAPI headers can all be built together with C++ (if the compiler being used supports C++). Note that it's based on a commit from the sound tree to fix usage of u32 and co.. Most of the patches perform fixups, including: (1) Fix member names that conflict with C++ reserved words by providing

Split the vSockets header into kernel and UAPI parts. The former gets the bits that used to be in __KERNEL__ guards, while the latter gets everything that is user-visible. Tested by compiling vsock (+transport) and a simple user-mode vSockets application. Reported-by: David Howells <dhowells at redhat.com> Acked-by: Dmitry Torokhov <dtor at vmware.com> Signed-off-by: Andy King

Split the vSockets header into kernel and UAPI parts. The former gets the bits that used to be in __KERNEL__ guards, while the latter gets everything that is user-visible. Tested by compiling vsock (+transport) and a simple user-mode vSockets application. Reported-by: David Howells <dhowells at redhat.com> Acked-by: Dmitry Torokhov <dtor at vmware.com> Signed-off-by: Andy King

The virtio_net_ctrl_hdr struct uses a C++ keyword as structural members. Fix this by inserting an anonymous union that provides an alternative name and then hide the reserved name in C++. Signed-off-by: David Howells <dhowells at redhat.com> cc: "Michael S. Tsirkin" <mst at redhat.com> cc: Jason Wang <jasowang at redhat.com> cc: virtualization at

The virtio_net_ctrl_hdr struct uses a C++ keyword as structural members. Fix this by inserting an anonymous union that provides an alternative name and then hide the reserved name in C++. Signed-off-by: David Howells <dhowells at redhat.com> cc: "Michael S. Tsirkin" <mst at redhat.com> cc: Jason Wang <jasowang at redhat.com> cc: virtualization at

Michael S. Tsirkin <mst at redhat.com> wrote: > As long as you do not intend to use any classes, how about > simply adding > > -Dclass=_class > > to your command line? That kind of misses the point;-). It's not reasonable to expect all userspace C++ users to do this. David

On Tue, Jan 26, 2016 at 11:32:00AM +0100, Peter Zijlstra wrote: > On Tue, Jan 26, 2016 at 11:24:02AM +0100, Peter Zijlstra wrote: > > > Yeah, this goes under the header: memory-barriers.txt is _NOT_ a > > specification (I seem to keep repeating this). > > Do we want this ? > > --- > Documentation/memory-barriers.txt | 17 +++++++++++++++++ > 1 file changed,

On Tue, Jan 26, 2016 at 11:32:00AM +0100, Peter Zijlstra wrote: > On Tue, Jan 26, 2016 at 11:24:02AM +0100, Peter Zijlstra wrote: > > > Yeah, this goes under the header: memory-barriers.txt is _NOT_ a > > specification (I seem to keep repeating this). > > Do we want this ? > > --- > Documentation/memory-barriers.txt | 17 +++++++++++++++++ > 1 file changed,

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer

On Thu, Jan 14, 2016 at 02:20:46PM -0800, Paul E. McKenney wrote: > On Thu, Jan 14, 2016 at 01:24:34PM -0800, Leonid Yegoshin wrote: > > On 01/14/2016 12:48 PM, Paul E. McKenney wrote: > > > > > >So SYNC_RMB is intended to implement smp_rmb(), correct? > > Yes. > > > > > >You could use SYNC_ACQUIRE() to implement read_barrier_depends() and >

On Thu, Jan 14, 2016 at 02:20:46PM -0800, Paul E. McKenney wrote: > On Thu, Jan 14, 2016 at 01:24:34PM -0800, Leonid Yegoshin wrote: > > On 01/14/2016 12:48 PM, Paul E. McKenney wrote: > > > > > >So SYNC_RMB is intended to implement smp_rmb(), correct? > > Yes. > > > > > >You could use SYNC_ACQUIRE() to implement read_barrier_depends() and >

This series introduce virtio-net features VIRTIO_NET_F_RSC_EXT, VIRTIO_NET_F_RSS and VIRTIO_NET_F_HASH_REPORT. Changes from v1: __virtio -> __le maximal -> maximum minor style fixes Yuri Benditovich (3): virtio-net: Introduce extended RSC feature virtio-net: Introduce RSS receive steering feature virtio-net: Introduce hash report feature include/uapi/linux/virtio_net.h | 90

This series introduce virtio-net features VIRTIO_NET_F_RSC_EXT, VIRTIO_NET_F_RSS and VIRTIO_NET_F_HASH_REPORT. Changes from v1: __virtio -> __le maximal -> maximum minor style fixes Yuri Benditovich (3): virtio-net: Introduce extended RSC feature virtio-net: Introduce RSS receive steering feature virtio-net: Introduce hash report feature include/uapi/linux/virtio_net.h | 90

This series introduce virtio-net features VIRTIO_NET_F_RSC_EXT, VIRTIO_NET_F_RSS and VIRTIO_NET_F_HASH_REPORT. Changes from v2: reformatted structure in patch 1 Yuri Benditovich (3): virtio-net: Introduce extended RSC feature virtio-net: Introduce RSS receive steering feature virtio-net: Introduce hash report feature include/uapi/linux/virtio_net.h | 100 ++++++++++++++++++++++++++++++--

This series introduce virtio-net features VIRTIO_NET_F_RSC_EXT, VIRTIO_NET_F_RSS and VIRTIO_NET_F_HASH_REPORT. Changes from v2: reformatted structure in patch 1 Yuri Benditovich (3): virtio-net: Introduce extended RSC feature virtio-net: Introduce RSS receive steering feature virtio-net: Introduce hash report feature include/uapi/linux/virtio_net.h | 100 ++++++++++++++++++++++++++++++--

On Sun, Mar 01, 2020 at 01:07:31PM +0200, Yuri Benditovich wrote: > VIRTIO_NET_F_RSC_EXT feature bit indicates that the device > is able to provide extended RSC information. When the feature > is negotiatede and 'gso_type' field in received packet is not > GSO_NONE, the device reports number of coalesced packets in > 'csum_start' field and number of duplicated acks

Provide a splice_read stub for ocfs2. This emits trace lines and does an atime lock/update before calling filemap_splice_read(). Splicing from direct I/O is handled by the caller. A couple of new tracepoints are added for this purpose. Signed-off-by: David Howells <dhowells at redhat.com> cc: Christoph Hellwig <hch at lst.de> cc: Al Viro <viro at zeniv.linux.org.uk> cc: Jens

Changes since v2: handling for devices without config space (e.g. rng) reduce # of mappings for VQs These patches seem to work fine on my virtio-1.0 qemu branch. There haven't been any bugs since v2: just minor cleanups and enhancements. QEMU side is still undergoing polishing, but is already testable. Rusty, what do you think? Let's merge these for 3.20? Also - will you be doing that

Changes since v2: handling for devices without config space (e.g. rng) reduce # of mappings for VQs These patches seem to work fine on my virtio-1.0 qemu branch. There haven't been any bugs since v2: just minor cleanups and enhancements. QEMU side is still undergoing polishing, but is already testable. Rusty, what do you think? Let's merge these for 3.20? Also - will you be doing that

From: Amos Kong <akong at redhat.com> Currenly mac is programmed byte by byte. This means that we have an intermediate step where mac is wrong. Second patch introduced a new vq control command to set mac address in one time. Amos Kong (2): move virtnet_send_command() above virtnet_set_mac_address() virtio-net: introduce a new control to set macaddr drivers/net/virtio_net.c |