* [Ksummit-discuss] UAPI headers and inline function policy @ 2017-01-23 11:20 ` David Howells 2017-01-23 11:35 ` Greg KH 2017-01-23 17:27 ` David Howells 0 siblings, 2 replies; 3+ messages in thread From: David Howells @ 2017-01-23 11:20 UTC (permalink / raw) To: ksummit-discuss; +Cc: mchehab, hans.verkuil, apw, joe 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Ksummit-discuss] UAPI headers and inline function policy 2017-01-23 11:20 ` [Ksummit-discuss] UAPI headers and inline function policy David Howells @ 2017-01-23 11:35 ` Greg KH 2017-01-23 17:27 ` David Howells 1 sibling, 0 replies; 3+ messages in thread From: Greg KH @ 2017-01-23 11:35 UTC (permalink / raw) To: David Howells; +Cc: mchehab, apw, joe, hans.verkuil, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Ksummit-discuss] UAPI headers and inline function policy 2017-01-23 11:20 ` [Ksummit-discuss] UAPI headers and inline function policy David Howells 2017-01-23 11:35 ` Greg KH @ 2017-01-23 17:27 ` David Howells 1 sibling, 0 replies; 3+ messages in thread From: David Howells @ 2017-01-23 17:27 UTC (permalink / raw) To: Hans Verkuil; +Cc: mchehab, ksummit-discuss, apw, hans.verkuil, joe 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-01-23 17:27 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <521f636c-c768-2d01-18c6-e5b6b96b6d8f@cisco.com>
2017-01-23 11:20 ` [Ksummit-discuss] UAPI headers and inline function policy David Howells
2017-01-23 11:35 ` Greg KH
2017-01-23 17:27 ` David Howells
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox