Re: 2.6.0-test11: i2c-dev.h for userspace

[davidsen@tmr.com (bill davidsen)]

In article <20031212190105.GB3038@kroah.com>, Greg KH  <greg@kroah.com> wrote:

| They aren't.  The rule is:
| 	DO NOT INCLUDE KERNEL HEADER FILES IN USERSPACE TOOLS.
| Please read the archives for lkml on why this is true.
| 
| Yeah, we do need a way to have "sanitized" kernel headers so that
| userspace can include them, but for now, use what your libc provides.
| 
| So please use the headers that are present in the lmsensors project, or
| copy those headers into your project.
| 
| I don't want this thread to drag out into the usual argument for or
| against this issue, please.

I think you are pissing into the wind on this one, as long as people
have the choice between a kernel header which will always have the right
definitions and trying to find a header elsewhere which will work until
the kernel changes again, people are going to use kernel headers.

Not that I disagree with the intent at all, it's better software
engineering to do it that way. Your desired practice is totally correct
and a better way to do it.

However, in the real world, it might be a lot better to have an ABI
header directory, and to have both the user and kernel programs get
unformation from that. The kernel could do its thing and still be in
step with the user program (modulo recompilation when kernel development
is taking place). Packages and libraries could be compiled using the ABI
includes and be certain they would work on new kernels. And developers
would have a clear indication that if they changed things in the ABI
includes they would mess up compiled user programs. That's not a bad
thing either.

On a development kernel finding other headers is more work and less
reliable, human nature doesn't work well that way.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.