Subject: Re: CVS commit: [elad-kernelauth] src/sys/ufs/ext2fs
To: Christos Zoulas <christos@zoulas.com>
From: Elad Efrat <elad@NetBSD.org>
List: source-changes
Date: 04/20/2006 21:16:30
Christos Zoulas wrote:
> On Apr 20,  9:31am, thorpej@shagadelic.org (Jason Thorpe) wrote:
> -- Subject: Re: CVS commit: [elad-kernelauth] src/sys/ufs/ext2fs
> 
> | On Apr 20, 2006, at 9:17 AM, Christos Zoulas wrote:
> | 
> | > The problem with this approach is that it needs <sys/kauth.h> to be
> | > present in all the header files that use the type. Unfortunately this
> | 
> | No, the problem is that prototypes and other structures that use a  
> | kauth_cred_t are being exposed to userland.  If you eliminate that,  
> | then you eliminate the need for userland to know anything kauth_cred- 
> | anything, and you only include <sys/kauth.h> #ifdef _KERNEL.
> 
> You cannot do that in some cases (the fsck sources for example, I showed
> in the previous message). Can you please explain to me what is the
> practical advantage of using a typedef vs. a struct pointer? Yes, from
> a purist's POV a typedef to an opaque type is better (because it could
> be any type not just a struct pointer), but you need to bring the typedef
> into scope. Doing so you actually expose more information that you are 
> if you are just having a forward struct declaration.

Userland should not use anything inside a kauth_cred_t, and so I don't
see a problem with using #ifdef _KERNEL around kauth.h's kernel-only
parts, and adding a userspace-only typedef for kauth_cred_t to a void *
which is unused anyway.

What guarantees that people don't start directly accessing members of
struct kauth_cred?

-e.

-- 
Elad Efrat