[i2c] py-smbus needs i2c-dev.h to be installed to build

Jean Delvare khali at linux-fr.org
Wed Jun 27 20:54:14 CEST 2007


Hi Trent,

On Wed, 27 Jun 2007 08:28:41 -0700 (PDT), Trent Piepho wrote:
> On Wed, 27 Jun 2007, Jean Delvare wrote:
> > As I moved py-smbus to the new i2c-tools package, I noticed that
> > building it only works if the i2c-dev.h header file is already
> > installed on the system. This doesn't sound right. I believe that one
> > should be able to build py-smbus before the i2c-tools package is
> > installed. What do you think?
> 
> I've noticed that the i2c-dev.h that comes with the kernel isn't useful for
> compiling userspace programs.  e.g. after running the kernel's headers
> check, the file the kernel puts in ./usr/include/linux/i2c-dev.h isn't any
> good.  It just some decoy file to make you think you have i2c-dev.h when
> you don't.

This is true.

>            This the file that most of the distros seem to include as part
> of their headers, so you can't build any i2c-dev programs out of the box.
> You have to first download the real i2c-dev.h and install that.

This is true as well, I noticed this today on my openSuse system too.
It also includes many other i2c-*.h kernel header files which are
completely useless in user-space. This needs to be cleaned up.

> It's seems like it's becoming kernel policy that the userspace system
> includes should be produced automatically from the kernel includes, so
> maybe having i2c-dev.h follow this would be a good idea.

A little bit of history is useful to understand why i2c-dev.h is the
way it it. Originally, there was a single i2c-dev.h file, and it was
living in the kernel tree. But several years ago, it was decided that
kernel headers should never be included in user-space. So we were asked
to create a separate i2c-dev.h header file for user-space inclusion,
and we did. And now, the rules have changed in the other direction, and
all the header files for user-space should be generated from the kernel
header files. So we'd need to merge both copies into a single file.

But it's not that easy. The first problem is that one part of the
user-space's i2c-dev.h is in i2c.h in the kernel, rather than in
i2c-dev.h. If we stick to the new rules, this means that user-space
developers will need to include two header files from now on
(<linux/i2c.h> and <linux/i2c-dev.h>). This can probably be worked
around by including <linux/i2c.h> in i2c-dev.h itself though, making the
change transparent for the users.

The second problem is that there are additional inline functions in the
user-space's i2c-dev.h, without which writing user-space applications
doing SMBus transactions would be way less convenient. These functions
do NOT make any sense in the kernel, so there's no reason to have them
in the kernel tree. I don't know what the rules will be for this case,
but I can easily imaging that we won't be allowed to put them in the
kernel. Which is probably right, anyway, because these helper inline
functions don't have much to do with kernel headers. So they probably
should live in a separate file. And while we're at it, it seems to me
that these helper functions were made inline because it was easier that
way. But some of these are quite big, and it doesn't look right to
inline them. So maybe they should rather be distributed in a small
library, either dynamic or static.

Don't get me wrong, I'm happy that things finally get cleared up in
this area and I do appreciate the work done by David Woodhouse. I'm
just pointing out that this won't be a trivial change as far as
i2c-dev.h is concerned.

-- 
Jean Delvare



More information about the i2c mailing list