2.6.0-test11: i2c-dev.h for userspace

2.6.0-test11: i2c-dev.h for userspace

[Johannes Stezenbach]

Hi,

I had some trouble compiling a userspace application
which uses the I2C device interface (the DirectFB
Matrox driver). Apparently some stuff has been removed
from i2c-dev.h, and Documentation/i2c/dev-interface is
out of date. I'm using Debian unstable (where glibc is
built with kernel 2.6 headers).

The patch below puts back some "#if __KERNEL__" conditionals
so i2c.h can be included without errors in userspace progams.

Regards,
Johannes



--- linux-2.6.0-test11-bk8/include/linux/i2c.h.orig	2003-12-12 15:19:12.000000000 +0100
+++ linux-2.6.0-test11-bk8/include/linux/i2c.h	2003-12-12 15:19:37.000000000 +0100
@@ -28,21 +28,26 @@
 #ifndef _LINUX_I2C_H
 #define _LINUX_I2C_H
 
+#ifdef __KERNEL__
 #include <linux/module.h>
-#include <linux/types.h>
-#include <linux/i2c-id.h>
 #include <linux/device.h>	/* for struct device */
 #include <asm/semaphore.h>
+#endif
+#include <linux/types.h>
+#include <linux/i2c-id.h>
 
 /* --- General options ------------------------------------------------	*/
 
 struct i2c_msg;
+union i2c_smbus_data;
+
+#ifdef __KERNEL__
+
 struct i2c_algorithm;
 struct i2c_adapter;
 struct i2c_client;
 struct i2c_driver;
 struct i2c_client_address_data;
-union i2c_smbus_data;
 
 /*
  * The master routines are the ones normally used to transmit data to devices
@@ -384,6 +389,7 @@
 
 /* Return 1 if adapter supports everything we need, 0 if not. */
 extern int i2c_check_functionality (struct i2c_adapter *adap, u32 func);
+#endif /* #if __KERNEL__ */
 
 /*
  * I2C Message - used for pure i2c transaction, also from /dev interface
@@ -530,6 +536,8 @@
 				/* written byte (except address)	*/
 #define I2C_MDELAY	0x0706	/* millisec delay between written bytes */
 
+
+#ifdef __KERNEL__
 /* ----- I2C-DEV: char device interface stuff ------------------------- */
 
 #define I2C_MAJOR	89		/* Device major number		*/
@@ -605,5 +613,6 @@
 	set_current_state(TASK_INTERRUPTIBLE);
 	schedule_timeout(timeout);
 }
+#endif /* #if __KERNEL__ */
 
 #endif /* _LINUX_I2C_H */
--- linux-2.6.0-test11-bk8/include/linux/i2c-dev.h.orig	2003-12-12 15:19:17.000000000 +0100
+++ linux-2.6.0-test11-bk8/include/linux/i2c-dev.h	2003-12-12 15:19:37.000000000 +0100
@@ -25,6 +25,7 @@
 #define _LINUX_I2C_DEV_H
 
 #include <linux/types.h>
+#include <linux/compiler.h>
 
 /* Some IOCTL commands are defined in <linux/i2c.h> */
 /* Note: 10-bit addresses are NOT supported! */

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

[Greg KH]

On Fri, Dec 12, 2003 at 03:56:52PM +0100, Johannes Stezenbach wrote:
> 
> I had some trouble compiling a userspace application
> which uses the I2C device interface (the DirectFB
> Matrox driver). Apparently some stuff has been removed
> from i2c-dev.h

Yes it has.  Do not use the kernel headers in your userspace
application.  If you need this interface, use the updated i2c-dev.h that
is in the lmsensors release.  That is the proper file.

thanks,

greg k-h

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

[Johannes Stezenbach]

On Fri, Dec 12, 2003 at 09:56:57AM -0800, Greg KH wrote:
> On Fri, Dec 12, 2003 at 03:56:52PM +0100, Johannes Stezenbach wrote:
> > 
> > I had some trouble compiling a userspace application
> > which uses the I2C device interface (the DirectFB
> > Matrox driver). Apparently some stuff has been removed
> > from i2c-dev.h
> 
> Yes it has.  Do not use the kernel headers in your userspace
> application.  If you need this interface, use the updated i2c-dev.h that
> is in the lmsensors release.  That is the proper file.

I think you create a mess here. Other drivers have usable
API include files in /usr/include/linux, why are i2c.h and i2c-dev.h
special?

While I can understand why the ioctl wrappers have been removed
from the kernel include file i2c-dev.h I fail to see the logic
in having a different i2c-dev.h for userspace, or generally breaking
the kernel includes for userspace.

It seems to me that there is no package that I could install to make
the correct i2c-dev.h available for userspace programs, and the only
way to fix the DirectFB Matrox driver so it compiles with 2.4 and
2.6 kernel headers is to copy the correct i2c-dev.h into the
DirectFB source tree.

I think that sucks.


Johannes

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

[Greg KH]

On Fri, Dec 12, 2003 at 07:53:57PM +0100, Johannes Stezenbach wrote:
> On Fri, Dec 12, 2003 at 09:56:57AM -0800, Greg KH wrote:
> > On Fri, Dec 12, 2003 at 03:56:52PM +0100, Johannes Stezenbach wrote:
> > > 
> > > I had some trouble compiling a userspace application
> > > which uses the I2C device interface (the DirectFB
> > > Matrox driver). Apparently some stuff has been removed
> > > from i2c-dev.h
> > 
> > Yes it has.  Do not use the kernel headers in your userspace
> > application.  If you need this interface, use the updated i2c-dev.h that
> > is in the lmsensors release.  That is the proper file.
> 
> I think you create a mess here. Other drivers have usable
> API include files in /usr/include/linux, why are i2c.h and i2c-dev.h
> special?

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 that sucks.

Sorry you feel that way, but the i2c header is not going to be any
different than any other kernel header at this time.

greg k-h

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

[Johannes Stezenbach]

On Fri, Dec 12, 2003 at 11:01:05AM -0800, Greg KH wrote:
> On Fri, Dec 12, 2003 at 07:53:57PM +0100, Johannes Stezenbach wrote:
> > 
> > I think you create a mess here. Other drivers have usable
> > API include files in /usr/include/linux, why are i2c.h and i2c-dev.h
> > special?
> 
> 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.

I've read this statement multiple times on lkml, from Linus
and others. And you won't believe it: I'm all for a separation
of driver API includes and kernel includes.

But:

> 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.

IMHO the problem is that Linux 2.6.0 is about to be released with some
broken driver API include files, and without a clear policy how driver
authors, glibc and distribution maintainers and should handle
the situation in a consistent way.


> > I think that sucks.
> 
> Sorry you feel that way, but the i2c header is not going to be any
> different than any other kernel header at this time.

I think they are different now.


Johannes

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

[Greg KH]

On Fri, Dec 12, 2003 at 08:21:32PM +0100, Johannes Stezenbach wrote:
> 
> IMHO the problem is that Linux 2.6.0 is about to be released with some
> broken driver API include files, and without a clear policy how driver
> authors, glibc and distribution maintainers and should handle
> the situation in a consistent way.

I'm not going to apply this patch, sorry.

greg k-h

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

[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.