In article <20070218155936.GX24282@snowdrop.l8s.co.uk>,
David Laight  <david@l8s.co.uk> wrote:
>On Sun, Feb 18, 2007 at 10:34:02AM -0500, Thor Lancelot Simon wrote:
>> On Sun, Feb 18, 2007 at 02:10:23PM +0000, David Laight wrote:
>> > The kauth code seems to be full of wrapper functions.
>> > 
>> > In particular every peice of code that needs to look at one of the
>> > process's uids ends up calling a function.
>> > This might be reasonable for LKMs, but for code that is linked into the
>> > main kernel image rather OTT.
>> > 
>> > Of course, this involves making the structure in kauth_impl.h publicly
>> > visible :-)
>> 
>> I actually prefer that access to UIDs be opaque in this way and think
>> it's a useful architectural feature of kauth.
>> 
>> Why don't we put the accessor functions in a header file and make them
>> inline?
>
>Or #defines, I have no problem with that.

The problem is that once the #defines or inlines exist in a header, users
of the defines/inlines will include that header to get the definitions.
At this point both the structure and the defines/inlines become visible
to the users, and nobody can prevent the users to use the field members
of the functions directly instead of going through the inlines.

There is an ugly way to prevent this, by using cpp macros to destroy
the member definitions after the inline function is defined. Eg.

struct foo {
	int foo_id;
};

static __inline int
get_foo_id(const struct foo *p) {
	return p->foo_id;
}

#define foo_id error

I think that the above is overkill and if there are performance issues we
can fix them in the future. What Elad was trying to avoid is to start on
a slippery slope by exposing the struct in a header in the first place.
Now that the structure has been exposed, we are starting to consider accessing
the members through inline functions...

christos