[Ksummit-discuss] UAPI headers and inline function policy

[Ksummit-discuss] UAPI headers and inline function policy

[David Howells]

I noticed that include/uapi/linux/cec.h and cec-funcs.h export a bunch of
inline functions to userspace.  I think that the following should possibly be
prohibited in kernel UAPI headers:

 (1) Inline functions and function declarations.

 (2) Anonymous embedded structs and unions.

 (3) Conditionals, other than re-inclusion guards and C++ guards.  Definitely
     no dependencies on CONFIG_* or __ARCH_* or __KERNEL__.  Ideally, we
     should be able to copy the headers as-are to /usr/include/ without the
     need to run them through a filter.

 (4) The extern keyword - except when used in a C++ guard.

Now, we already have some violations of these that we probably can't get rid
of, but anything added in the last merge window we probably can deal with.

Thoughts?

David

Re: [Ksummit-discuss] UAPI headers and inline function policy

[Greg KH]

On Mon, Jan 23, 2017 at 11:20:25AM +0000, David Howells wrote:
> I noticed that include/uapi/linux/cec.h and cec-funcs.h export a bunch of
> inline functions to userspace.  I think that the following should possibly be
> prohibited in kernel UAPI headers:
> 
>  (1) Inline functions and function declarations.

As the lustre filesystem wants to do the same thing that cec is doing,
where would the best place be to put stuff like this that would
otherwise just require two independant copies to be kept in sync?

thanks,

greg k-h

Re: [Ksummit-discuss] UAPI headers and inline function policy

[David Howells]

Hans Verkuil <hansverk@cisco.com> wrote:

> >  (1) Inline functions and function declarations.
> 
> The reason for putting them there is that these inline functions are used
> both in the kernel and in userspace. Having them in one place makes life
> much simpler.
> 
> What is the rationale for not allowing this?
> 
> >  (2) Anonymous embedded structs and unions.
> 
> Same question. Anonymous unions are used in many places and have been for
> many years. Certainly in the media subsystem they are used frequently.

Not all compilers support these features.  Also, we have to be very careful
about using reserved words like "new" in parameter and variable names.

David