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++). All but the final patch perform fixups, including:
(1) Fix member names that conflict with C++ reserved words by providing alternates that can be used anywhere. An anonymous union is used so that that the conflicting name is still available outside of C++.
(2) Fix the use of flexible arrays in structs that get embedded (which is illegal in C++).
(3) Remove the use of internal kernel structs in UAPI structures.
(4) Fix symbol collisions.
(5) Replace usage of u32 and co. with __u32 and co.
(6) Fix use of sparsely initialised arrays (which g++ doesn't implement).
(7) Remove some use of PAGE_SIZE since this isn't valid outside of the kernel.
And lastly:
(8) Compile all of the UAPI headers (with a few exceptions) together as C++ to catch new errors occurring as part of the regular build process.
The patches can also be found here:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=uap...
Thanks, David --- David Howells (11): UAPI: drm: Fix use of C++ keywords as structural members UAPI: keys: Fix use of C++ keywords as structural members UAPI: virtio_net: Fix use of C++ keywords as structural members UAPI: bcache: Fix use of embedded flexible array UAPI: coda: Don't use internal kernel structs in UAPI UAPI: netfilter: Fix symbol collision issues UAPI: nilfs2: Fix use of undefined byteswapping functions UAPI: sound: Fix use of u32 and co. in UAPI headers UAPI: ndctl: Fix g++-unsupported initialisation in headers UAPI: ndctl: Remove use of PAGE_SIZE UAPI: Check headers build for C++
Makefile | 1 include/linux/ndctl.h | 22 ++++ include/uapi/drm/i810_drm.h | 7 + include/uapi/drm/msm_drm.h | 7 + include/uapi/linux/bcache.h | 2 include/uapi/linux/coda_psdev.h | 4 + include/uapi/linux/keyctl.h | 7 + include/uapi/linux/ndctl.h | 20 ++- include/uapi/linux/netfilter/nfnetlink_cthelper.h | 2 include/uapi/linux/netfilter_ipv4/ipt_ECN.h | 9 -- include/uapi/linux/nilfs2_ondisk.h | 21 ++-- include/uapi/linux/virtio_net.h | 7 + include/uapi/sound/skl-tplg-interface.h | 106 +++++++++--------- scripts/headers-c++.sh | 124 +++++++++++++++++++++ 14 files changed, 255 insertions(+), 84 deletions(-) create mode 100644 include/linux/ndctl.h create mode 100755 scripts/headers-c++.sh
The i810 and msm drm drivers use C++ keywords 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@redhat.com cc: Rob Clark robdclark@gmail.com cc: David Airlie airlied@linux.ie cc: linux-arm-msm@vger.kernel.org cc: dri-devel@lists.freedesktop.org cc: freedreno@lists.freedesktop.org ---
include/uapi/drm/i810_drm.h | 7 ++++++- include/uapi/drm/msm_drm.h | 7 ++++++- 2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/include/uapi/drm/i810_drm.h b/include/uapi/drm/i810_drm.h index d285d5e72e6a..617d79ec3fc5 100644 --- a/include/uapi/drm/i810_drm.h +++ b/include/uapi/drm/i810_drm.h @@ -266,7 +266,12 @@ typedef struct _drm_i810_copy_t { #define PR_MASK (0x7<<18)
typedef struct drm_i810_dma { - void *virtual; + union { +#ifndef __cplusplus + void *virtual; +#endif + void *_virtual; + }; int request_idx; int request_size; int granted; diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h index c06d0a5bdd80..e99bab72d58c 100644 --- a/include/uapi/drm/msm_drm.h +++ b/include/uapi/drm/msm_drm.h @@ -148,7 +148,12 @@ struct drm_msm_gem_cpu_fini { */ struct drm_msm_gem_submit_reloc { __u32 submit_offset; /* in, offset from submit_bo */ - __u32 or; /* in, value OR'd with result */ + union { +#ifndef __cplusplus + __u32 or; /* in, value OR'd with result */ +#endif + __u32 _or; /* in, value OR'd with result */ + }; __s32 shift; /* in, amount of left shift (can be negative) */ __u32 reloc_idx; /* in, index of reloc_bo buffer */ __u64 reloc_offset; /* in, offset from start of reloc_bo */
On Wed, Sep 05, 2018 at 04:54:27PM +0100, David Howells wrote:
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++). All but the final patch perform fixups, including:
Wait, why do we care? What has recently changed to start to directly import kernel uapi files into C++ code?
And if userspace wants to do this, can't they do the C namespace trick themselves when they do the import? That must be how they are doing it today, right?
thanks,
greg k-h
Hi,
Le mercredi 05 septembre 2018 à 18:55 +0200, Greg KH a écrit :
On Wed, Sep 05, 2018 at 04:54:27PM +0100, David Howells wrote:
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++). All but the final patch perform fixups, including:
Wait, why do we care? What has recently changed to start to directly import kernel uapi files into C++ code?
And if userspace wants to do this, can't they do the C namespace trick themselves when they do the import? That must be how they are doing it today, right?
They can't.
Adding extern "C" { } doesn't magically make "class" a non keyword. Even if it was the case, writing C++ code using whatever->class would probably broke because class is a keyword in C++.
On Wed, Sep 05, 2018 at 07:33:38PM +0200, Yann Droneaud wrote:
Hi,
Le mercredi 05 septembre 2018 à 18:55 +0200, Greg KH a écrit :
On Wed, Sep 05, 2018 at 04:54:27PM +0100, David Howells wrote:
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++). All but the final patch perform fixups, including:
Wait, why do we care? What has recently changed to start to directly import kernel uapi files into C++ code?
And if userspace wants to do this, can't they do the C namespace trick themselves when they do the import? That must be how they are doing it today, right?
They can't.
Adding extern "C" { } doesn't magically make "class" a non keyword. Even if it was the case, writing C++ code using whatever->class would probably broke because class is a keyword in C++.
I think it's a bug in the language TBH.
-- Yann Droneaud OPTEYA
Le mercredi 05 septembre 2018 à 19:33 +0200, Yann Droneaud a écrit :
Le mercredi 05 septembre 2018 à 18:55 +0200, Greg KH a écrit :
On Wed, Sep 05, 2018 at 04:54:27PM +0100, David Howells wrote:
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++). All but the final patch perform fixups, including:
Wait, why do we care? What has recently changed to start to directly import kernel uapi files into C++ code?
And if userspace wants to do this, can't they do the C namespace trick themselves when they do the import? That must be how they are doing it today, right?
They can't.
Adding extern "C" { } doesn't magically make "class" a non keyword. Even if it was the case, writing C++ code using whatever->class would probably broke because class is a keyword in C++.
For the record, libX11 has to handle the kink pf issue with C++ keyword:
https://gitlab.freedesktop.org/xorg/lib/libx11/blob/733f64bfeb311c1d040b2f75...
typedef struct { XExtData *ext_data; /* hook for extension to hang data */ VisualID visualid; /* visual id of this visual */ #if defined(__cplusplus) || defined(c_plusplus) int c_class; /* C++ class of screen (monochrome, etc.) */ #else int class; /* class of screen (monochrome, etc.) */ #endif unsigned long red_mask, green_mask, blue_mask; /* mask values */ int bits_per_rgb; /* log base 2 of distinct color values */ int map_entries; /* color map entries */ } Visual;
Regards.
Greg KH greg@kroah.com wrote:
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++). All but the final patch perform fixups, including:
Wait, why do we care? What has recently changed to start to directly import kernel uapi files into C++ code?
There's at least one outstanding bug due to a C++ identifier in the kernel UAPI headers.
Are you saying you explicitly don't want people to be able to use the kernel UAPI headers in C++?
And if userspace wants to do this, can't they do the C namespace trick themselves when they do the import? That must be how they are doing it today, right?
No, because there's no such trick (except with the preprocessor).
David
On Wednesday 2018-09-05 18:55, Greg KH wrote:
On Wed, Sep 05, 2018 at 04:54:27PM +0100, David Howells wrote:
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++). All but the final patch perform fixups, including:
Wait, why do we care? What has recently changed to start to directly import kernel uapi files into C++ code?
With C++11, C++ has become a much nicer language to use (for userspace, anyway).
And if userspace wants to do this, can't they do the C namespace trick themselves when they do the import?
The only trick is to use an extra C source file and extensively wrap things.
dri-devel@lists.freedesktop.org
-
David Howells -
Greg KH -
Jan Engelhardt -
Michael S. Tsirkin -
Yann Droneaud