why is there still so much __KERNEL__ testing in include/uapi/?
continuing down this road of exporting kernel headers, under include/uapi/ (and mostly further under linux/), there's still a *ton* of testing of the __KERNEL__ preprocessor check. now, i realize that when one does "make headers_install", all those files are run through "unifdef" to sanitize almost all of that kernel content, so it's not like it hurts, but is there any reason so much of it is still there? wouldn't it be tidier to get rid of it? or is there some rationale for leaving it there? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
On Fri, May 27, 2016 at 12:08:09PM -0400, Robert P. J. Day wrote:
continuing down this road of exporting kernel headers, under include/uapi/ (and mostly further under linux/), there's still a *ton* of testing of the __KERNEL__ preprocessor check.
now, i realize that when one does "make headers_install", all those files are run through "unifdef" to sanitize almost all of that kernel content, so it's not like it hurts, but is there any reason so much of it is still there? wouldn't it be tidier to get rid of it?
No, because not all of the information in those .h files should be exported to userspace. You could either split the files all up into two different ones, or just live with the existing infrastructure we have. We chose the easy one :) greg k-h
On Fri, 27 May 2016, Greg KH wrote:
On Fri, May 27, 2016 at 12:08:09PM -0400, Robert P. J. Day wrote:
continuing down this road of exporting kernel headers, under include/uapi/ (and mostly further under linux/), there's still a *ton* of testing of the __KERNEL__ preprocessor check.
now, i realize that when one does "make headers_install", all those files are run through "unifdef" to sanitize almost all of that kernel content, so it's not like it hurts, but is there any reason so much of it is still there? wouldn't it be tidier to get rid of it?
No, because not all of the information in those .h files should be exported to userspace. You could either split the files all up into two different ones, or just live with the existing infrastructure we have. We chose the easy one :)
ok, i think i see *part* of my misunderstanding so let me back up a bit ... are any of the header files *directly* under include/linux processed for exporting? because there is no file include/linux/Kbuild, which i assume needs to exist for that to happen. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
On Fri, 27 May 2016, Greg KH wrote:
On Fri, May 27, 2016 at 12:08:09PM -0400, Robert P. J. Day wrote:
continuing down this road of exporting kernel headers, under include/uapi/ (and mostly further under linux/), there's still a *ton* of testing of the __KERNEL__ preprocessor check.
now, i realize that when one does "make headers_install", all those files are run through "unifdef" to sanitize almost all of that kernel content, so it's not like it hurts, but is there any reason so much of it is still there? wouldn't it be tidier to get rid of it?
No, because not all of the information in those .h files should be exported to userspace. You could either split the files all up into two different ones, or just live with the existing infrastructure we have. We chose the easy one :)
ok, after further perusal, i can see the misunderstandings i had, mostly because i'd never read the rationale and design for UAPI closely enough. originally, i thought the whole point of the uapi/ directories was to factor out, as thoroughly as possible, user space-only header file content, and certainly there are header files where there is a beautiful, clean break between kernel space stuff and user space stuff, so splitting such a file into two parts is easy. so my first mistake was thinking that there should be very little __KERNEL__ checking in the uapi/ directories. there are, of course, cases where it's just not feasible to do a perfect partitioning, like in cases where a single structure definition might contain: #ifdef __KERNEL__ some member #else some other member #endif so, sure, that sort of thing would be retained in a uapi/ header file, and would be finally sanitized as part of the headers install process. what i'm massively embarrassed to admit is that i didn't know the uapi/ directories are part of the normal kernel header file search path: # Use USERINCLUDE when you must reference the UAPI directories only. USERINCLUDE := \ -I$(srctree)/arch/$(hdr-arch)/include/uapi \ -Iarch/$(hdr-arch)/include/generated/uapi \ -I$(srctree)/include/uapi \ -Iinclude/generated/uapi \ -include $(srctree)/include/linux/kconfig.h # Use LINUXINCLUDE when you must reference the include/ directory. # Needed to be compatible with the O= option LINUXINCLUDE := \ -I$(srctree)/arch/$(hdr-arch)/include \ -Iarch/$(hdr-arch)/include/generated/uapi \ -Iarch/$(hdr-arch)/include/generated \ $(if $(KBUILD_SRC), -I$(srctree)/include) \ -Iinclude \ $(USERINCLUDE) which means that rather than trying to refactor a header file into kernel and user space parts, you can just say, "ah, the heck with it," and move it into uapi/, where it will be the *only* version of that header file in the kernel source tree, suitable for use in both kernel and user space. case in point: $ find . -name virtio_blk.h ./include/uapi/linux/virtio_blk.h $ and in cases like that, sure, there could be all sorts of __KERNEL__ checking going on to distinguish kernel space content from user space content. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
participants (2)
-
Greg KH -
Robert P. J. Day