Re: [PATCH 2/5] nfsd: Fix independence of a few nfsd related headers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/22/2009 02:28 AM, Trond Myklebust wrote:
> On Wed, 2009-10-21 at 10:14 +0200, Boaz Harrosh wrote:
>> An header should be compilation independent, .i.e pull in
>> any header who's declarations are directly used by this header.
>> And not let users re-include all it's dependencies all over
>> again.
>>
>> [At the end of the day what's the use of a header if it does
>>  not have more then one user?]
> 
> 
> The problem with this is that you quickly end up including the same
> header files over and over and over again as they get pulled in several
> times over by different headers.
> 
> 
> 

What is the problem with that?

two things:
1. it is unavoidable.
2. That's why we invented the #ifndef FOO_H #define FOO_H for.
3. Look at the current mess, to the point that you don't understand why
   the code does not compile, you end up just copy-past the include list
   of that other file, and now actually do end with extra un-needed includes.
   (Don't believe me look at the last patch as proof).
4. So I add to an header a use of a type that now needs a new include.
   All my users do not compile any more. What to do? OK I'll include it so
   not to change all existing users all over again. Now we get a double
   standard. All headers used before any users, must be carried around.
   The late comers are escaped.
5. The opposite of 4. An header is no longer needed. Extra header left at all
   users.

It used to be a problem before me and you have begun programing.
Since then the cpp looks at it's internal structures and will not re-open.
Note that the compiler never sees the second instance, ever.

That said we have no choice of the matter. It is a Kernel style guide. I
should know because I was banged on the head with it a couple of times.
And rightly so.

Come on that was a joke right
Boaz
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux