khali at linux-fr.org
Fri Nov 14 22:55:16 CET 2003
> > > Is it split up into small, incremental patches, each patch only
> > > doing one thing? That is what is going to be required if it will
> > > be accepted into the kernel tree.
> > Basically, it's all or nothing.
> Hm, with that attitude, your patch will go nowhere, sorry.
Interesting. Sleepless nights building these patches to drivers I mostly
don't use, writing an installation guide, setting a place up for
download, answering questions and fixing bugs. Highly questionable
> Again, you are going to _have_ to build up a series of patches, each
> only doing one thing, in order to try to get these changes into the
The i2c subsystem as we know it was first introduced in the 2.3.34
kernel back in November 1999 (it was version i2c-2.4.4). In kernel
2.4.13 it was updated to i2c-2.6.1. No trace of that on the LKML, so I
can't say how this happened. This was more than two years ago. Albert
Cranford since tried to have it updated. He sent split patches to the
LKML and did not have any (public) answer, not even one. The patches
were rejected (so I guess, since kernel 2.4.22 still has i2c-2.6.1).
The idea is that i2c is developped on a separate CVS repository, and is
periodically integrated to the kernel. Don't ask me why, I don't know.
What I wan't you to understand is that it doesn't make sense to split
patches in these conditions. It would if we were sending updates every
few weeks or months. Changes could be discussed in real time, things
that wouldn't be accepted in the kernel would be changed in the CVS
repository. But this hasn't been done for 26 months. I let you imagine
how much has been done during this time. I also let you imagine that
many changes depend on others. And you must realize that none of us can
remember everything that was changed during that long period. What's
more, people that were working on the project back in 2001 (Frodo
Looijaard, Kyösti Mälkki, Simon Vigl) have left by now, sometimes with
changes half done.
After structure changes occured as we released i2c-2.8.0 and we became
incompatible with what can be found in Linux 2.4, we felt we would have
to submit a patch to the LKML to synchronize with 2.4's i2c subsystem
again. Being jobless, I had enough spare time and volunteered to build
such a patch. This was a rather hard work and I wonder if anyone would
have done this, if not me. I had some difficulties building the
i2c-2.8.0 patch in time to submit it to the LKML for inclusion into
Linux 2.4.22, and again I was late with the i2c-2.8.1 patch for Linux
2.4.23. I have been working almost alone on this.
Splitting this patch before submitting it makes no sense to me. First
because building subpatches that could really be accepted or rejected
independently and still lead to a working subsystem is unlikely after
two years of changes. If someone were able to to this, I'm not
that someone. Second because rejecting part of the patch isn't really an
option for the kernel folks. Whatever will be in the Linux 2.4 kernel
tree has to match what we have in our CVS repository. Nobody wants to
(not has the time to) keep these two places in sync forever.
Don't misunderstand me, I don't pretend that the kernel folks just have
to take my patch without a question, with no chance to discuss specific
points. I mean that if parts of the patch are not OK, we'll update the
our CVS repository accordingly, so that in the end we have exactly the
same thing in linux 2.4 and our CVS repository. We can't remember
forever that some specific portion of code shouldn't make it to the
Linux kernel and still keep it in our CVS version. This would be plain
It's not like posting something totally new to the LKML and expect
everyone to trust me when I say my code is great. This code has been
over-tested. Look at our rank at Freshmeat. And the patch itself has
been downloaded around 2000 times, with enough feedback to believe it
has been well tested, and few enough bug reports to believe it worked
out of the box for almost everyone.
> The fact that you are going to be changing an existing api,
> and breaking working drivers, in a stable kernel series so late in the
> development process, is going to be a big problem in getting your
> patches accepted.
I'm not the one that decided we would break the existing API. I did my
best to provide the needed patch, no more, no less. That said, the
change isn't a big one as far as I can tell (take a look at what it
takes to convert an existing driver, it's straightforward). What's more,
it lets drivers clean their module usage count method to follow what the
kernel folks pretend is the right way to do (if I understood it well).
Third point, it matches what was made in Linux 2.5/2.6 (if you don't
know that, who does?) so 1* it can't be fundamentally broken and 2* it
helps third-party driver developers (having the same driver working in
both Linux 2.4 and 2.6).
>You better do them in the least obtrusive manner possible.
I can't think of something better than "here is a patch that brings the
i2c subsystem to 2.8.1". I'd have expected the kernel guys to be aware
of our work, and to trust us. I've tried to send very simple,
preliminary patches. See:
I had no answer, and as far as I can see, the patches I've sent have
been silently ignored and dropped, although these were really simple and
could have been obviously applied directly without a risk. As long as I
have no guarantee that my work won't be more considered than that, I
have no reason to spend more time on this. I now have a job and less
time for this kind of time-consuming activities. I also have a
girlfriend who would like me to spend a little more time with her and a
little less with you all.
And yes, I have read the LKML FAQ. I know that the kernel folks are more
important than I am, have less free time than I have and must have
better things to do than listening to me. But what's the point in a
mailing-list in this case? And what's the point in open-source software
in these conditions?
> Good luck,
I don't need luck. I don't truly believe in luck anyway.
What I need is assistance. I obviously can't succeed if I'm the only
one struggling against invisible forces. I have been mostly working
alone so far. If I can't get my voice heard on the LKML, someone
else will have to replace me, but actually I doubt anyone is interested
in my place.
What I want you to understand is that I won't have time to do the things
the way you pretend I should do them (nor do I think the things should
be done that way; again, our CVS has hundreds, if not thousands, of
fellow testers that have been fairly happy for the past two years). And
if I don't do it, I don't expect anyone to do it. If the kernel guys
don't want of my patch, our CVS branch will be forever incompatible with
Linux 2.4. Since I won't update my patch forever, this could also mean
the end of our CVS development and the death of the lm_sensors project
as we know it, with over a year of work almost lost.
Or we could get some help from people involved in kernel development,
with enough influence to convince a kernel maintainer that our i2c
subsystem is well tested and stable enough to be integrated into the
kernel. This would eventually put an end to the nightmare we're into.
After all, the i2c subsystem isn't a really sensible one, and I can't
understand why so much trouble would be required just to get it updated.
Which side are you on, Greg?
More information about the lm-sensors