2.8.1

2.8.1

[Mark Studebaker]

fine w/ me if you want to release 2.8.1 soon.
I don't have anything pending, other than applying a big and conflicting
patch to i2c-ali1535 that was submitted months ago;
which I'm not going to get to and couldn't test anyway.
Does anybody have a 1535?

here is the relevant email and patch

http://archives.andrew.net.au/lm-sensors/msg03556.html

no rush to get it into 2.8.1 that I can see.


> Phil, when do you think you'll have some time to release 2.8.1?
> 
> --
> Jean Delvare

2.8.1

[Jean Delvare]

> I wanted to update kernels and userland for 2.8.1 but the install
> guide contains only i2c-patches for 2.8.0.
> 
> Do the 2.8.0 patched out-of-the-tree kernel modules (ivtv, bttv etc.)
> need any further patching?

2.8.0 and 2.8.1 are the same WRT structure problems, so yes, modules
still require patching, using the same patches.

You'll find a patch for Linux 2.4.22 on my guide page, it was built
using I2C CVS right before the 2.8.1 release, so this is almost a 2.8.1
patch. I'm working on an "official" 2.4.22 patch right now, should be
ready within an hour (just updating the HTML page now, the patch itself
is already ready) and maybe another hour for me to update the two
download sources. I'll let you know as soon as it's ready, since I guess
you'll be wanting to give it a try (and I want testers ;)).

Thanks for your interest in my work and serious in your releases.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

2.8.1

[Jean Delvare]

Hi Axel, hi all,

I just uploaded new i2c patches for the Linux 2.4.22 kernel based on the
freshly released 2.8.1 i2c. This patchset will be the base of the patch
I'll post to the LKML for inclusion. It will require some changes to
apply cleanly to 2.4.23-pre8, but basically that's it. Everyone is
welcome to test it. I've myself checked that it would at least compile,
but I can't test everything. Some drivers can only be compiled on
non-x86 systems, so I can't hardly test them. For the rest of the
drivers, I'll test them on the hardware I do have, but I of course don't
have all the required hardware.

So everyone please review, test and comment my patch before I will
submit it to the kernel folks. I'd really like it to be included to
Linux 2.4.23.

Thanks.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

2.8.1

[Greg KH]

On Sun, Oct 26, 2003 at 07:26:01PM +0100, Jean Delvare wrote:
> 
> Hi Axel, hi all,
> 
> I just uploaded new i2c patches for the Linux 2.4.22 kernel based on the
> freshly released 2.8.1 i2c.

Uploaded where?

Care to send it to the list (and cc me, as I'm not keeping up on my
sensors traffic due to Real Life stuff right now...)?

> This patchset will be the base of the patch I'll post to the LKML for
> inclusion.

It needs to be a set of incremental patches, that do not break the API
for any current drivers.  Hm, it's also a bit late in the 2.4.23-pre
series to expect to get this in, but we can work on that.

thanks,

greg k-h

2.8.1

[Jean Delvare]

> > I just uploaded new i2c patches for the Linux 2.4.22 kernel based on
> > the freshly released 2.8.1 i2c.
> 
> Uploaded where?

http://www.ensicaen.ismra.fr/~delvare/devel/i2c/

Sorry, I though you had it in your bookmarks. What do I say, bookmarks.
As your starting page, yeah! ;)

> Care to send it to the list (and cc me, as I'm not keeping up on my
> sensors traffic due to Real Life stuff right now...)?

I usually avoid sending 250kB patches on mailing list, unless I am
explicitely invited to do so. I guess that interested people will go to
the download page, won't they?

Well, you must be right, I probably will have a larger audiance if I
push the patch to the people rather than letting them come to it. But
I'm now that kind of guy I guess.

> > This patchset will be the base of the patch I'll post to the LKML
> > for inclusion.
> 
> It needs to be a set of incremental patches, that do not break the API
> for any current drivers.  Hm, it's also a bit late in the 2.4.23-pre
> series to expect to get this in, but we can work on that.

Take a look at the above-mentioned page, the patch is splitted over
logical units. I guess that's how you expect things to be.

I know it's a bit late for .23, especially since the patch is rather
large. However, it was already a bit late for .22 last time. I don't
really care, but our users do. This is much trouble for them having to
patch their kernel to prevent it from crashing as soon as they use
i2c-related drivers (bttv...). So that would be great if we could make
an exception this time. After all, I2C isn't a critical subsystem, and
my previous patch has been successfully tested by many users on various
systems. And our patch allow i2c drivers to get rid of MOD_*_USE_COUNT
calls, so I guess the kernel folks will like it. It also i2c-related
driver authors who will now be able to have unified drivers for Linux
2.4 and 2.6. Hopefully these good reasons will be enough to convince
everyone that this patch should make it through 2.4.23.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

2.8.1

[Greg KH]

On Sun, Oct 26, 2003 at 07:52:48PM +0100, Jean Delvare wrote:
> > > This patchset will be the base of the patch I'll post to the LKML
> > > for inclusion.
> > 
> > It needs to be a set of incremental patches, that do not break the API
> > for any current drivers.  Hm, it's also a bit late in the 2.4.23-pre
> > series to expect to get this in, but we can work on that.
> 
> Take a look at the above-mentioned page, the patch is splitted over
> logical units. I guess that's how you expect things to be.

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.

thanks,

greg k-h

2.8.1

[Jean Delvare]

> 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. The core patch updates the i2c subsystem
to 2.8.1. Then you have to patch Config.in and Makefile to make it work
(two more patches). At this point, you have a working i2c subsystem, but
all drivers using it (and not being part of i2c 2.8.1) are broken, so
all of them need to be fixed. Some of them are in drivers/i2c (8 more
patches, possibly merged into a few less), and the other ones spread
other the whole kernel tree (6 more patches).

The only patch left apart is the one that updates MAINTAINERS. Not even
worth mentioning I guess.

The way the patches are split might be reviewed somehow, but it won't
change the fundamental idea: you have to apply them all at once. I guess
it'll make it harder to get them accepted in the kernel, but there's no
other way I can imagine. And, although many files are affected, it's
always the same way. Patches are very, very simple, so there shouldn't
be much to be discussed on a per file basis.

I hope thet the kernel guys will be convinced that this is a good thing,
worth doing, though. Among positive points I can see, are:

1* It'll make it easier to use lm_sensors. Since 2.8.0, people can't
build lm_sensors without patching their kernels.

2* It'll make it easier to write "independant" (neither in kernel nor in
i2c/lm_sensors2 CVS) i2c drivers. For now, if authors want to support
both 2.4 and 2.6, they have to play with ifdef's all over their code. If
i2c 2.8.1 makes it through Linux 2.4, authors will be able to get rid of
that extra code.

3* The change makes it possible to (and was actually designed to) get
rid of MOD_{INC,DEC}_USE_COUNT in i2c drivers. I think that's something
they are wanting.

If there are other advantages worth mentioning, let me know so that I
can add them to the list.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

2.8.1

[Greg KH]

On Tue, Nov 04, 2003 at 08:31:27PM +0100, Jean Delvare wrote:
> 
> > 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.

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
kernel.  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.  You better do them in the least obtrusive manner
possible.

Good luck,

greg k-h

2.8.1

[Jean Delvare]

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

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

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

http://marc.theaimsgroup.com/?w=2&r=1&s=2.4.20-pre5+i2c+patch&q=t

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

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:

http://marc.theaimsgroup.com/?t\x106831100400004&r=1&w=2
http://marc.theaimsgroup.com/?t\x106849321700002&r=1&w=2
http://marc.theaimsgroup.com/?t\x106849321900001&r=1&w=2

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?

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

2.8.1

[Greg KH]

On Fri, Nov 14, 2003 at 10:55:16PM +0100, Jean Delvare wrote:
> 
> > > > 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
> attitude indeed.

Um, I'm referring to your "Take it or leave it, here's the big patch
that syncs up with our CVS tree" attitude.  I'm not referring to all of
the work you have done for the project at all.  I think you have done a
lot of very good, very needed work for the sensors project, and thank
you for it.

But when you try to ignore the way kernel development works, I don't
have much sympathy.  Please read Documentation/SubmittingPatches for how
to send patches into the kernel.  It states that you have to split them
up.  Also read Documentation/CodingStyle and see that numerous drivers
in the current cvs tree do not follow this basic style.  For that reason
alone, the patch will be rejected.

And the argument that this is a "resync" with an external CVS tree, or
that thousands of users love the result doesn't fly either.  See the
numerous posts by Linus on linux-kernel about how he does not accept big
code dumps.  I'm not going to reiterate the reasons why here again.

Also realize that you are trying to modify a very stable kernel tree,
that is nearing it's end of life cycle.  2.6 will be shipping in distros
in 6 months, and in it, the sensors code.  Because of this it is going
to be a very hard sell to do such a massive code dump, and api change in
2.4.  Now I'm not saying that the api change is not a good thing
technically, just realize that you are very late to this tree, and so
the ability to change things is harder and harder.

This is one of the main reasons I worked so hard to get the sensors code
into 2.5, as that was the proper time to do it.  I also fixed the coding
style issues, and logic issues and submitted patches in small,
incremental chunks to introduce these changes.  In short, I followed the
rules, and the patches were accepted.

Please don't be frustrated.  The rules are spelled out in very nice
detail, don't be surprised at resistance when you try to ignore them.

> Which side are you on, Greg?

I think I'll let my kernel work, done on my own time, speak for itself.

thanks,

greg k-h

2.8.1

[Jean Delvare]

> But when you try to ignore the way kernel development works, I don't
> have much sympathy.  Please read Documentation/SubmittingPatches for
> how to send patches into the kernel.  It states that you have to split
> them up.  Also read Documentation/CodingStyle and see that numerous
> drivers in the current cvs tree do not follow this basic style.  For
> that reason alone, the patch will be rejected.

As I had to modify a dozen drivers when building my patches, I can tell
you that many of them don't follow any rules. No C99 initializers, no
tabs used for alignement, improper module reference count (of course,
this is why I had to patch them) and more. And the *are* in the
2.4.22 kernel.

What's more, this kernel has i2c-2.6.1, which doesn't comply with any
rule either. 2.8.1 is in no way worse, it would even tend to be better.
Mind you, this is why we want it in.

> And the argument that this is a "resync" with an external CVS tree, or
> that thousands of users love the result doesn't fly either.  See the
> numerous posts by Linus on linux-kernel about how he does not accept
> big code dumps.  I'm not going to reiterate the reasons why here
> again.

Correct me if I'm wrong, but isn't it what happened for ACPI? It was
developped on a separate repository, and merged later. I doubt they
split it up into pieces. And ACPI is much more sensible than I2C.

> Also realize that you are trying to modify a very stable kernel tree,
> that is nearing it's end of life cycle.

What you say here is that we should *not* have been doing that interface
change in CVS. I now tend to think you are right. Still this was done
(and not by me) and I don't think any of us want to change back.

In these conditions, I would have appreciated not to be encouraged by
you and a few others to write that patch I have been working on. If
there is absolutely no chance it will be accepted as-is, and as I don't
have the time nor the knowledge to split two years of changes into
logical pieces, this basically means I worked for nothing.

Anyway, 2.4 isn't possibly in its end of life cycle. Last patch was over
5MB bz2'd. The three previous ones have been around 4MB bz2'd. Don't
call that a dying kernel.

> 2.6 will be shipping in distros in 6 months, and in it, the sensors
> code.

Remember what happened with 2.4. Yes, it shipped in distros starting
with 2.4.5, but did not become actually stable before 2.4.16. I wonder
if the distro makers and the users will do the same error again. My bet
is that most server maintainers will stick to 2.4 for another year or
so. And it happens that these are the folks who need sensors support the
most.

> Because of this it
> is going to be a very hard sell to do such a massive code dump, and
> api change in 2.4.  Now I'm not saying that the api change is not a
> good thing technically, just realize that you are very late to this
> tree, and so the ability to change things is harder and harder.

Again, I agree. Still you keep telling me what should have been done
for the two last years (that is, porting changes to the kernel every
month). This wasn't done and I wasn't even there.

What I'd like you to tell me instead is what I am supposed to do now.
Give it all up and leave the users helpless? Go on updating my patch
for every new kernel for the next two or three years?

(If you have not done so yet, I invite you to go and watch "Anything
Else" by Woody Allen. Great movie.)

> This is one of the main reasons I worked so hard to get the sensors
> code into 2.5, as that was the proper time to do it.  I also fixed the
> coding style issues, and logic issues and submitted patches in small,
> incremental chunks to introduce these changes.  In short, I followed
> the rules, and the patches were accepted.

This was a development kernel. You *could* slice your changes and have
them in a public kernel the day after you submit them. I believe this is
quite different for 2.4.

> Please don't be frustrated.

I could hardly be more. Yes, I know, my attitude etc etc.

> The rules are spelled out in very nice
> detail, don't be surprised at resistance when you try to ignore them.

Rules, as laws, are guidelines. Some follow them, some don't. Some get
caught and some don't. But more interestingly, some never follow them
and never get caught, while some eventually don't follow them and get
caught. But I agree I might be off-topic here.

I respect the spirit of the rules. I agree that's how things should be
done. The point is: now that things cannot (in the real world) be done
that way, what are we supposed to do?

> > Which side are you on, Greg?
> 
> I think I'll let my kernel work, done on my own time, speak for
> itself.

Admitedly my question lacked subtlety, please forgive me.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/