Re: CVS commit: [elad-kernelauth] src/sys/ufs/ext2fs

[christos%zoulas.com@localhost (Christos Zoulas)]

On Apr 20,  2:03pm, thorpej%shagadelic.org@localhost (Jason Thorpe) wrote:
-- Subject: Re: CVS commit: [elad-kernelauth] src/sys/ufs/ext2fs

| 
| On Apr 20, 2006, at 10:57 AM, Christos Zoulas wrote:
| 
| > Userland code is using ext2fs_bswap.c which is a kernel file. A kernel
| 
| ext2fs_bswap.c's prototypes are in ext2fs.h, not ext2fs_extern.h.   
| ext2fs_bswap.c does not include ext2fs_extern.h.  So this change was  
| not needed, unless some other sloppiness is involved (and that's what  
| it is, sloppiness).
| 
| Next example?
| 
| > file is including the kernel header. The other fsck's do this too.
| > Really, it is good enough to use "struct kauth_cred *". This is why
| > we don't have a lot of typedefs in the kernel: so that we don't have
| > to include the world to make things compile. Your example of vaddr_t
| > just proves my point. Can we please reach consensus on this so I can
| > commit the changes and so we can move on? You still have not replied
| > on the practical advantage of using a typedef vs. using a struct  
| > pointer...
| 
| The practical advantage is making kauth_cred_t as opaque as  
| possible.  What if we change the implementation later to be an index  
| into some table?  Then we're just going to have to change all this  
| code again.

Is this really a possibility? Even then it would probably be better
to have a struct and an index in it.

Let me present a different argument: Imagine a kernel with proc_t,
lwp_t, user_t, file_t, socket_t, etc. Where are you going to put
all these typedefs? In a single file? Because you will not be able
to deal with the circular dependencies otherwise. Each typedef added
adds enough pain to maintain...

christos