i2c-tools: Discussion points about future library

i2c-tools: Discussion points about future library

[Jean Delvare]

Hi all,

There are two points which may need to be discussed concerning the
upcoming library in i2c-tools [1] [2].

[1] http://www.lm-sensors.org/wiki/I2CTools_4_Plan
[2] http://marc.info/?l=linux-i2c&m=133182689203486&w=2

First point is the name of the library. My original intent was to name
it libi2c-dev, because the library is essentially a front-end to the
i2c-dev kernel driver, and also because this is what Debian named their
package currently containing the (i2c-tools flavor of)
<linux/i2c-dev.h>. However Aurélien Jarno suggested that libi2c would
be just as fine, and easier/shorter. I am mostly convinced by now. I am
curious if anyone wants to express an opinion on the matter?

Second point is the creation of a header file to ease the migration of
tools from the old model (i2c-tools flavor of <linux/i2c-dev.h>) to the
new model (library with its header files + unchanged kernel headers).
Right now, the migration path looks like this:

+#include <sys/ioctl.h>
+#include <i2c/smbus.h>
 #include <linux/i2c-dev.h>

for SMBus tools, and this:

+#include <sys/ioctl.h>
+#include <linux/i2c.h>
 #include <linux/i2c-dev.h>
 
for I2C tools. I am happy with this, but Aurélien insisted that it
would be more friendly if tools only needed to include one header file
in order to make use of the library. For this we would need to create
an extra header file only including the other header files. Something
like <i2c/i2c.h> containing:

#include <sys/ioctl.h>
#include <linux/i2c.h>
#include <linux/i2c-dev.h>
#include <i2c/smbus.h>

This would have the downside that tools end up (indirectly) including
header files they don't necessarily need. And migrating every tool is
still needed, as you would then still have to do:

-#include <linux/i2c-dev.h>
+#include <i2c/i2c.h>

I admit this is slightly easier than my initial plan, but the benefit
doesn't strike me as fundamental. Here again I would appreciate if
users of the i2c-dev driver could comment on this. I know that
libsensors (the only library I am intimately familiar with) does not
provide such an extra header file, but that's only one example so it
might not be relevant.

Thanks,
-- 
Jean Delvare

Re: i2c-tools: Discussion points about future library

[Mark Brown]

On Wed, Apr 04, 2012 at 04:01:13PM +0200, Jean Delvare wrote:

> First point is the name of the library. My original intent was to name
> it libi2c-dev, because the library is essentially a front-end to the
> i2c-dev kernel driver, and also because this is what Debian named their
> package currently containing the (i2c-tools flavor of)
> <linux/i2c-dev.h>. However Aur??lien Jarno suggested that libi2c would
> be just as fine, and easier/shorter. I am mostly convinced by now. I am
> curious if anyone wants to express an opinion on the matter?

FWIW the Debian convention is that the source package of a library is
called libfoo building packages libfoo-dev with the headers and .so
symlink to link against (or .a for a static library) and libfooN with
the runtime in it (where N is the soname).

Re: i2c-tools: Discussion points about future library

[Jean Delvare]

Hi Mark,

On Wed, 4 Apr 2012 18:41:58 +0100, Mark Brown wrote:
> On Wed, Apr 04, 2012 at 04:01:13PM +0200, Jean Delvare wrote:
> 
> > First point is the name of the library. My original intent was to name
> > it libi2c-dev, because the library is essentially a front-end to the
> > i2c-dev kernel driver, and also because this is what Debian named their
> > package currently containing the (i2c-tools flavor of)
> > <linux/i2c-dev.h>. However Aur??lien Jarno suggested that libi2c would
> > be just as fine, and easier/shorter. I am mostly convinced by now. I am
> > curious if anyone wants to express an opinion on the matter?
> 
> FWIW the Debian convention is that the source package of a library is
> called libfoo building packages libfoo-dev with the headers and .so
> symlink to link against (or .a for a static library) and libfooN with
> the runtime in it (where N is the soname).

Oh, OK, so I completely misinterpreted the -dev. I am used to -devel
for development packages (openSUSE) so the connection did not happen in
my brain. Of course it makes sense now.

So I guess I'll name the library libi2c.

Thanks,
-- 
Jean Delvare

Re: i2c-tools: Discussion points about future library

[Martin Mokrejs]

Hi,
  did you Google for it? Looks "libi2c" is already existing.

http://www.rtems.com/ml/rtems-users/2008/march/msg00033.html
http://packages.ubuntu.com/search?keywords=libi2c-dev

  I would also search for the header filenames and invent such names
which will not clash with any existing. Same for "-li2c" or
whatever will apear on the ld line.
Martin

Jean Delvare wrote:
> Hi Mark,
> 
> On Wed, 4 Apr 2012 18:41:58 +0100, Mark Brown wrote:
>> On Wed, Apr 04, 2012 at 04:01:13PM +0200, Jean Delvare wrote:
>>
>>> First point is the name of the library. My original intent was to name
>>> it libi2c-dev, because the library is essentially a front-end to the
>>> i2c-dev kernel driver, and also because this is what Debian named their
>>> package currently containing the (i2c-tools flavor of)
>>> <linux/i2c-dev.h>. However Aur??lien Jarno suggested that libi2c would
>>> be just as fine, and easier/shorter. I am mostly convinced by now. I am
>>> curious if anyone wants to express an opinion on the matter?
>>
>> FWIW the Debian convention is that the source package of a library is
>> called libfoo building packages libfoo-dev with the headers and .so
>> symlink to link against (or .a for a static library) and libfooN with
>> the runtime in it (where N is the soname).
> 
> Oh, OK, so I completely misinterpreted the -dev. I am used to -devel
> for development packages (openSUSE) so the connection did not happen in
> my brain. Of course it makes sense now.
> 
> So I guess I'll name the library libi2c.
> 
> Thanks,

Re: i2c-tools: Discussion points about future library

[Martin Mokrejs]

One more: http://opensource.katalix.com/libi2c/

Martin Mokrejs wrote:
> Hi,
>   did you Google for it? Looks "libi2c" is already existing.
> 
> http://www.rtems.com/ml/rtems-users/2008/march/msg00033.html
> http://packages.ubuntu.com/search?keywords=libi2c-dev
> 
>   I would also search for the header filenames and invent such names
> which will not clash with any existing. Same for "-li2c" or
> whatever will apear on the ld line.
> Martin
> 
> Jean Delvare wrote:
>> Hi Mark,
>>
>> On Wed, 4 Apr 2012 18:41:58 +0100, Mark Brown wrote:
>>> On Wed, Apr 04, 2012 at 04:01:13PM +0200, Jean Delvare wrote:
>>>
>>>> First point is the name of the library. My original intent was to name
>>>> it libi2c-dev, because the library is essentially a front-end to the
>>>> i2c-dev kernel driver, and also because this is what Debian named their
>>>> package currently containing the (i2c-tools flavor of)
>>>> <linux/i2c-dev.h>. However Aur??lien Jarno suggested that libi2c would
>>>> be just as fine, and easier/shorter. I am mostly convinced by now. I am
>>>> curious if anyone wants to express an opinion on the matter?
>>>
>>> FWIW the Debian convention is that the source package of a library is
>>> called libfoo building packages libfoo-dev with the headers and .so
>>> symlink to link against (or .a for a static library) and libfooN with
>>> the runtime in it (where N is the soname).
>>
>> Oh, OK, so I completely misinterpreted the -dev. I am used to -devel
>> for development packages (openSUSE) so the connection did not happen in
>> my brain. Of course it makes sense now.
>>
>> So I guess I'll name the library libi2c.
>>
>> Thanks,

Re: i2c-tools: Discussion points about future library

[Jean Delvare]

Hi Martin,

Please don't top-post.

On Wed, 04 Apr 2012 21:41:08 +0200, Martin Mokrejs wrote:
> Hi,
>   did you Google for it? Looks "libi2c" is already existing.

Yes I did.

> http://www.rtems.com/ml/rtems-users/2008/march/msg00033.html

RTEMS is an operating system on its own. We don't care what libraries
they have and what they named them, just as they don't care what
libraries Linux has and names them.

> http://packages.ubuntu.com/search?keywords=libi2c-dev

As you know, Ubuntu is derived from Debian, and I did mention in my
original post that Debian had a package named libi2c-dev. Meanwhile
Mark Brown explained that this is the development package for an
hypothetical libi2c package which doesn't (yet exist.) So I am aware of
this one and it is compatible with my effort.

> http://opensource.katalix.com/libi2c/

First time I hear of this. They never contacted me (nor the linux-i2c
list) about it, and more importantly, it doesn't seem to be packaged by
any major Linux distribution. Their API is different from what the
kernel and i2c-tools use. I can understand that they developed
something given the lack of a proper library for the past 10 years, but
they should have discussed it with the community to make it more
visible. I'm not saying Katalix is bad, they did work with the
community on other topics, but in this specific case they did not, and
that's unfortunate.

I'm not sure if they still maintain that code, BTW, this seems to be an
old page, if I go to http://www.katalix.com, I can't return to that
page.

I understand that having two libraries by the same name will cause some
confusion, but OTOH the parallel implementations and resulting
confusion already exist, I'm only making the confusion more formal.

>   I would also search for the header filenames and invent such names
> which will not clash with any existing. Same for "-li2c" or
> whatever will apear on the ld line.

No, sorry. I'm not going to invent a fancy name to make sure it isn't
clashing with something out there. If anyone wanted their code to
become the standard Linux i2c library, they should have pushed it to
major Linux distributions. Nobody did AFAICS.

-- 
Jean Delvare

Re: i2c-tools: Discussion points about future library

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 612 bytes --]

> >   I would also search for the header filenames and invent such names
> > which will not clash with any existing. Same for "-li2c" or
> > whatever will apear on the ld line.
> 
> No, sorry. I'm not going to invent a fancy name to make sure it isn't
> clashing with something out there. If anyone wanted their code to
> become the standard Linux i2c library, they should have pushed it to
> major Linux distributions. Nobody did AFAICS.

+1

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: i2c-tools: Discussion points about future library

[Martin Mokrejs]

Hi Jean,

Jean Delvare wrote:
> Hi Martin,
> 
> Please don't top-post.
> 
> On Wed, 04 Apr 2012 21:41:08 +0200, Martin Mokrejs wrote:
>> Hi,
>>   did you Google for it? Looks "libi2c" is already existing.
> 
> Yes I did.
> 
>> http://www.rtems.com/ml/rtems-users/2008/march/msg00033.html
> 
> RTEMS is an operating system on its own. We don't care what libraries
> they have and what they named them, just as they don't care what
> libraries Linux has and names them.
> 
>> http://packages.ubuntu.com/search?keywords=libi2c-dev
> 
> As you know, Ubuntu is derived from Debian, and I did mention in my
> original post that Debian had a package named libi2c-dev. Meanwhile
> Mark Brown explained that this is the development package for an
> hypothetical libi2c package which doesn't (yet exist.) So I am aware of
> this one and it is compatible with my effort.
> 
>> http://opensource.katalix.com/libi2c/
> 
> First time I hear of this. They never contacted me (nor the linux-i2c
> list) about it, and more importantly, it doesn't seem to be packaged by
> any major Linux distribution. Their API is different from what the
> kernel and i2c-tools use. I can understand that they developed
> something given the lack of a proper library for the past 10 years, but
> they should have discussed it with the community to make it more
> visible. I'm not saying Katalix is bad, they did work with the
> community on other topics, but in this specific case they did not, and
> that's unfortunate.
> 
> I'm not sure if they still maintain that code, BTW, this seems to be an
> old page, if I go to http://www.katalix.com, I can't return to that
> page.
> 
> I understand that having two libraries by the same name will cause some
> confusion, but OTOH the parallel implementations and resulting
> confusion already exist, I'm only making the confusion more formal.

Yes, that will be also a nightmare for distro maintainers, having same header
and library files installed simultaneously on a system, users having problems
which one to install ...


> 
>>   I would also search for the header filenames and invent such names
>> which will not clash with any existing. Same for "-li2c" or
>> whatever will apear on the ld line.
> 
> No, sorry. I'm not going to invent a fancy name to make sure it isn't
> clashing with something out there. If anyone wanted their code to
> become the standard Linux i2c library, they should have pushed it to
> major Linux distributions. Nobody did AFAICS.

No, sorry, don't take me wrong and not personally, at all witrh the following.
Once I read somewhere on the internet a rant from some software developer who
created program "foo". Later on, someone else decided to create a package
"foo2" and the original author commented that it was "nasty", as it appears
"foo2" is an improved version of "foo".

Back to our case, I find it "nasty" as well to say, now, X years later we have
our own library and will use exactly this name, as we don't care about you all.
We are the "official" ...

I hope I will not start a flame with this answer. Personally, I do not mind
but I just saw too many times packages using same library and header names.
Last time it was, that glibc since some newer version had a header file
of some name which some app used since years. I convinced the app author
to change his header name as it seemed more feasible than convincing glibc
people to take their decision back.

But you just asked beforehand, so I wanted to tell you my opinion. I would
contact Katalix to discuss, that would be fair thing to do.

Best,
Martin

Re: i2c-tools: Discussion points about future library

[Jean Delvare]

On Thu, 05 Apr 2012 11:42:10 +0200, Martin Mokrejs wrote:
> Jean Delvare wrote:
> > (...)
> > I understand that having two libraries by the same name will cause some
> > confusion, but OTOH the parallel implementations and resulting
> > confusion already exist, I'm only making the confusion more formal.
> 
> Yes, that will be also a nightmare for distro maintainers, having same header
> and library files installed simultaneously on a system, users having problems
> which one to install ...

I don't see any nightmare for distro maintainers (and I would mind, as
I am maintaining i2c-tools and thus will be maintaining libi2c, in
openSUSE.) Today there is no libi2c in distributions, tomorrow there
will be one, that's all OK. Likewise, users won't have any problem,
unless they fetch random code and build it themselves. If they do that,
I would assume they know what they're doing, and they can then install
the alternative implementation files under /opt or similar.

Again, it would be a problem if there was already a libi2c in
distributions, but it turns out this isn't the case. Unless you can
find a distribution with a non-negligible market share which actually
ships a library by that name.

Also note that, assuming for a moment that Katalix's libi2c has some
visibility and people are actually using it at wide (which I doubt,
IMHO users are limited to a few embedded platform developers), then the
confusion will not come from the fact that both libraries have the same
name, it will start with the fact that two libraries exist that achieve
the same purpose. The fact is that we do not need two libraries, so any
time spent on making it easy to install them in parallel, is wasted
time IMHO.

> > (...)
> > No, sorry. I'm not going to invent a fancy name to make sure it isn't
> > clashing with something out there. If anyone wanted their code to
> > become the standard Linux i2c library, they should have pushed it to
> > major Linux distributions. Nobody did AFAICS.
> 
> No, sorry, don't take me wrong and not personally, at all with the following.
> Once I read somewhere on the internet a rant from some software developer who
> created program "foo". Later on, someone else decided to create a package
> "foo2" and the original author commented that it was "nasty", as it appears
> "foo2" is an improved version of "foo".

I don't quite see how it relates to the problem at hand...

> Back to our case, I find it "nasty" as well to say, now, X years later we have
> our own library and will use exactly this name, as we don't care about you all.
> We are the "official" ...

We will indeed be "official" at the time distributions package and ship
our library. If others wanted to be "official", they had to get their
code visible and included in several distributions.

> I hope I will not start a flame with this answer. Personally, I do not mind
> but I just saw too many times packages using same library and header names.
> Last time it was, that glibc since some newer version had a header file
> of some name which some app used since years. I convinced the app author
> to change his header name as it seemed more feasible than convincing glibc
> people to take their decision back.

This is the problem with having a single namespace. This is the reason
why I will put the header files under /usr/include/i2c rather
than /usr/include directly. While not bullet-proof, this should limit
the risk of collisions.

> But you just asked beforehand, so I wanted to tell you my opinion. I would
> contact Katalix to discuss, that would be fair thing to do.

I'll put exactly the same amount of effort in contacting them now than
they put in contacting us 6 years ago. That is, none.

And don't get me wrong, I don't mean to be harsh with them. They wrote
a library because there was none at the time, and I understand that.
They decided their time was not worth spending on trying to get it into
distributions, and I understand and respect that too, everyone have
their priorities. And I don't even think they will have any problem
with what I'm doing now, because a library maintained by somebody else
means less work for them, and converting existing applications to use
it should be fairly easy.

So I'm not going to start a discussion with Katalix, because it's
rather unlikely that they care about what I'm doing, and if they do,
it's rather likely that it won't bother them at all.

-- 
Jean Delvare