Call for 2.9.0

Call for 2.9.0

[Jean Delvare]

Hi all,

I would like us to release i2c 2.9.0 (and obviously lm_sensors 2.9.0)
quite soon now. Before the end of the year would be great.

I am done with restoring the compatibility with Linux 2.4. I have an
update of my installation guide [1] ready (not online yet) for 2.9.0.
This should have been done one year ago, so better release it as soon as
possible now.

I would like everyone using lm_sensors on a 2.4 kernel on a regular
basis to give a try to i2c-CVS and lm_sensors-CVS now, and report if
problems arise. This is the biggest change to i2c since 2.8.0 so it
deserves some texting before we release it.

This also suggests that no more big changes to the CVS repositories
should be committed until after the release (unless anyone has prepared
something for a long time and commits them in the next few days).

Thanks,
-- 
Jean Delvare
http://khali.linux-fr.org/

Call for 2.9.0

[Mark Studebaker]

1) are you working on sensors README/QUICKSTART/INSTALL updates or are you looking for volunteers?

2) i2c-virtual and pca954x are checked in but not in the Makefiles, pending i2c-core changes required.
   I can do the core changes before or after 2.9.0. Attached is the i2c-core patch,
   slimmed down from that received from Brian Kuschak.
   It's really only two changes:
	- creating xxx_nolock versions of some calls
	- working up the bus tree for busy checks, using i2c_virt_parent()

   Not sure I like the i2c_virt_parent() hack (see kernel/include/i2c-virtual.h in sensors for the definition)
   and trying to think of a better way to do it.

   Anyway, comments on the patch and on the timing (before or after 2.9.0) welcome.

mds



Jean Delvare wrote:
> Hi all,
> 
> I would like us to release i2c 2.9.0 (and obviously lm_sensors 2.9.0)
> quite soon now. Before the end of the year would be great.
> 
> I am done with restoring the compatibility with Linux 2.4. I have an
> update of my installation guide [1] ready (not online yet) for 2.9.0.
> This should have been done one year ago, so better release it as soon as
> possible now.
> 
> I would like everyone using lm_sensors on a 2.4 kernel on a regular
> basis to give a try to i2c-CVS and lm_sensors-CVS now, and report if
> problems arise. This is the biggest change to i2c since 2.8.0 so it
> deserves some texting before we release it.
> 
> This also suggests that no more big changes to the CVS repositories
> should be committed until after the release (unless anyone has prepared
> something for a long time and commits them in the next few days).
> 
> Thanks,
-------------- next part --------------
--- i2c-core.c.orig	Sat Dec  4 22:52:48 2004
+++ i2c-core.c	Wed Dec  8 16:59:43 2004
@@ -78,12 +78,14 @@
  * i2c_add_adapter is called from within the algorithm layer,
  * when a new hw adapter registers. A new device is register to be
  * available for clients.
+ *
+ * i2c_add_adapter_nolock does the actual work.  It is split
+ * out so it can be called externally by i2c-virtual.c without deadlocking.
  */
-int i2c_add_adapter(struct i2c_adapter *adap)
+int i2c_add_adapter_nolock(struct i2c_adapter *adap)
 {
 	int i,j,res = 0;
 
-	down(&core_lists);
 	for (i = 0; i < I2C_ADAP_MAX; i++)
 		if (NULL = adapters[i])
 			break;
@@ -117,16 +119,32 @@
 	DEB(printk(KERN_DEBUG "i2c-core.o: adapter %s registered as adapter %d.\n",
 	           adap->name,i));
 ERROR0:
+	return res;
+}
+
+int i2c_add_adapter(struct i2c_adapter *adap)
+{
+	int res;
+
+	down(&core_lists);
+        res = i2c_add_adapter_nolock(adap);
 	up(&core_lists);
+
 	return res;
 }
 
 
-int i2c_del_adapter(struct i2c_adapter *adap)
+/*
+ * i2c_del_adapter is the corresponding function to detach all clients
+ * for a bus/adapter and then deregister it.
+ *
+ * i2c_del_adapter_nolock does the actual work.  It is split
+ * out so it can be called externally by i2c-virtual.c without deadlocking.
+ */
+int i2c_del_adapter_nolock(struct i2c_adapter *adap)
 {
 	int i,j,res = 0;
 
-	down(&core_lists);
 	for (i = 0; i < I2C_ADAP_MAX; i++)
 		if (adap = adapters[i])
 			break;
@@ -176,7 +194,17 @@
 	adapters[i] = NULL;
 	DEB(printk(KERN_DEBUG "i2c-core.o: adapter unregistered: %s\n",adap->name));
 ERROR0:
+	return res;
+}
+
+int i2c_del_adapter(struct i2c_adapter *adap)
+{
+	int res;
+
+	down(&core_lists);
+        res = i2c_del_adapter_nolock(adap);
 	up(&core_lists);
+
 	return res;
 }
 
@@ -297,13 +325,21 @@
 	return res;
 }
 
-static int __i2c_check_addr (struct i2c_adapter *adapter, int addr)
+static int i2c_check_addr_nolock (struct i2c_adapter *adapter, int addr)
 {
 	int i;
-	for (i = 0; i < I2C_CLIENT_MAX ; i++) 
+
+#if defined(CONFIG_I2C_VIRTUAL) || defined(CONFIG_I2C_VIRTUAL_MODULE)
+	/* Must check for aliasing on i2c-multiplexed busses since a virt
+         * bus will always appear to have its own mux as an address.  Without
+         * this check we can get infinite recursion during bus scans.
+         */
+	for ( ; adapter; adapter = i2c_virt_parent(adapter))
+#endif
+            for (i = 0; i < I2C_CLIENT_MAX ; i++) {
 		if (adapter->clients[i] && (adapter->clients[i]->addr = addr))
 			return -EBUSY;
-
+            }
 	return 0;
 }
 
@@ -312,7 +348,7 @@
 	int rval;
 
 	down(&adapter->list);
-	rval = __i2c_check_addr(adapter, addr);
+	rval = i2c_check_addr_nolock(adapter, addr);
 	up(&adapter->list);
 
 	return rval;
@@ -1470,6 +1506,8 @@
 
 EXPORT_SYMBOL(i2c_add_adapter);
 EXPORT_SYMBOL(i2c_del_adapter);
+EXPORT_SYMBOL(i2c_add_adapter_nolock);
+EXPORT_SYMBOL(i2c_del_adapter_nolock);
 EXPORT_SYMBOL(i2c_add_driver);
 EXPORT_SYMBOL(i2c_del_driver);
 EXPORT_SYMBOL(i2c_attach_client);

Call for 2.9.0

[Jean Delvare]

On 2004-12-09, Mark Studebaker wrote:

> 1) are you working on sensors README/QUICKSTART/INSTALL updates or are you
> looking for volunteers?

You're right, the documentation needs updates. Volunteers are of course
very welcome.

One thing we would need to discuss is whether we want to go on pretending
that we support kernels down to 2.4.9. Last time I checked, anything
before 2.4.17 would simply not compile. Given that kernels 2.4.11 and
2.4.15 were not even usable, I see little benefit in supporting any
kernel before 2.4.16, and even this one doesn't seem to be much used
anyone (thanks god). Thus I think it'd be more simple to simply say we
support kernels 2.4.17+.

If anyone were really interested in restoring support for the
2.4.9-2.4.16, i guess we would have received patches to do that. We
simply don't have the "internal" resources needed to check and/or
restore compatibility with older kernels ourselves, it seems.

> 2) i2c-virtual and pca954x are checked in but not in the Makefiles,
> pending i2c-core changes required.

Strange order, huh?

> I can do the core changes before or after 2.9.0. Attached is the i2c-core
> patch, slimmed down from that received from Brian Kuschak.
> It's really only two changes:
>  - creating xxx_nolock versions of some calls
>  - working up the bus tree for busy checks, using i2c_virt_parent()

Irk! How exactly is i2c-core supposed to know i2c_virt_parent when it's
defined by lm_sensors? How is it even supposed to know about
CONFIG_I2C_VIRTUAL (and what is CONFIG_I2C_VIRTUAL_MODULE?)? Looks like
a circular dependency issue to me.

Also, i2c-core should NOT export nolock functions. These functions (much
like
__i2c_check_addr) are meant for internal use only (thus the leading
underscores in the name, which should be used for the new functions as
well). Locks are implementation details not supposed to be even known by
the external users.

> Not sure I like the i2c_virt_parent() hack (see
> kernel/include/i2c-virtual.h in sensors for the definition) and trying
> to think of a better way to do it.

How exactly is it a hack?

> Anyway, comments on the patch and on the timing (before or after 2.9.0)
> welcome.

Definitely after. Doesn't sound correct to me at all, to say the truth.
It looks like things that would need to belong to the i2c-core were
added in lm_sensors instead.

Could you please summarize the approach that you are following, or point
me to an up-to-date document covering this if such a document exists? I
would like to understand how it would be implemented at the i2c-core
level, what interface it would expose to the other kernel drivers, and
if possible a real-world use case (an equivalent of i2c-amd756-s4882
using i2c-virtual would be great, for example.)

I'm suspicious about how this approach is better than what I did for the
S4882 motherboard, which didn't require any change to the i2c-core. As
I understand it, even with Brian's virtual busses, one would still have
to write a pseudo bus driver for each specific multiplexing design
(since such designs cannot be easily guessed and multiplexer chips are
hard to detect anyway). The only drawback of my approach is that I had
to export the original bus driver's i2c_adapter structure. Even that
might be worked around by simply providing a search-adapter-by-id
function in i2c-core (although with a slight loss of performance.)

Remember that bus multiplexing is only needed for a very limited number
of motherboards and a couple proprietary designs. This accounts for a
very limited total number of users and as such isn't worth breaking
working concepts or compatibility. I'm sorry to insist but I fear that
what you (and Brian) are trying to implement would belong to Linux 2.6,
not 2.4.

Thanks,
--
Jean Delvare

Call for 2.9.0

[Mark Studebaker]

Jean Delvare wrote:

> 
>>2) i2c-virtual and pca954x are checked in but not in the Makefiles,
>>pending i2c-core changes required.
> 
> 
> Strange order, huh?
> 
> 

I thought I did exactly as we discussed on IRC a few weeks ago.
You didn't want i2c-core changes at that time because you were working on 2.9.0.
I said I'd work on the i2c-virtual code received from Brian.
I checked it in to sensors for review and comment.
I thought that's what we agreed to.


>>I can do the core changes before or after 2.9.0. Attached is the i2c-core
>>patch, slimmed down from that received from Brian Kuschak.
>>It's really only two changes:
>> - creating xxx_nolock versions of some calls
>> - working up the bus tree for busy checks, using i2c_virt_parent()
> 
> 
> Irk! How exactly is i2c-core supposed to know i2c_virt_parent when it's
> defined by lm_sensors? How is it even supposed to know about
> CONFIG_I2C_VIRTUAL (and what is CONFIG_I2C_VIRTUAL_MODULE?)? Looks like
> a circular dependency issue to me.
> 

i2c-core needs to include i2c-virtual.h to get the i2c_virt_parent() definition -
but that wasn't in the patch I posted.

> Also, i2c-core should NOT export nolock functions. These functions (much
> like
> __i2c_check_addr) are meant for internal use only (thus the leading
> underscores in the name, which should be used for the new functions as
> well). Locks are implementation details not supposed to be even known by
> the external users.
> 

What Brian discovered is that an i2c bus mux implementation requires a nolock version
of some functions. Think about how the bootstrap works:
	Bus gets added
	Mux chip found
	Sub busses get added (but can't because lock still held - hang)
So that's what the (first half of) i2c-core patch does. Get rid of the leading '__', rename to xxx_nolock,
and export them so that the virtual driver can implement the bootstrap.

It's not a big change. Maybe there's a way to avoid it, though... I don't know.

> 
>>Not sure I like the i2c_virt_parent() hack (see
>>kernel/include/i2c-virtual.h in sensors for the definition) and trying
>>to think of a better way to do it.
> 
> 
> How exactly is it a hack?
> 

Well, it's either a "hack" or "icky". You said "ick" which I can agree with.

> 
>>Anyway, comments on the patch and on the timing (before or after 2.9.0)
>>welcome.
> 
> 
> Definitely after. Doesn't sound correct to me at all, to say the truth.
> It looks like things that would need to belong to the i2c-core were
> added in lm_sensors instead.
> 

It could have gone either place, what's the difference? You were in the middle
of i2c changes so I put it in sensors. Again, I thought this was what
we agreed to - I wouldn't make any i2c changes. We can move i2c-virtual.c to i2c
if you want. pca954x.c can't move because it's a chip driver.


> Could you please summarize the approach that you are following, or point
> me to an up-to-date document covering this if such a document exists? I
> would like to understand how it would be implemented at the i2c-core
> level, what interface it would expose to the other kernel drivers, and
> if possible a real-world use case (an equivalent of i2c-amd756-s4882
> using i2c-virtual would be great, for example.)
> 

Brian's document is checked in doc/busses/i2c-virtual. He also has extensive
comments in i2c-virtual.c and pca954x.c. So that's a start.
I'll try and come up with additional documentation.

Your other questions:
	- the implentation at the i2c-core level is simply the patch I posted yesterday
	- The code in sensors CVS _is_ the equivalent of i2c-amd756-4882. The
	  "real-world use case" is "modprobe i2c-amd756; modprobe i2c-virtual; modprobe pca9556 [params]",
          where pca9556 looks alot like pca954x.

> I'm suspicious about how this approach is better than what I did for the
> S4882 motherboard, which didn't require any change to the i2c-core. As
> I understand it, even with Brian's virtual busses, one would still have
> to write a pseudo bus driver for each specific multiplexing design
> (since such designs cannot be easily guessed and multiplexer chips are
> hard to detect anyway). The only drawback of my approach is that I had
> to export the original bus driver's i2c_adapter structure. Even that
> might be worked around by simply providing a search-adapter-by-id
> function in i2c-core (although with a slight loss of performance.)
> 
> Remember that bus multiplexing is only needed for a very limited number
> of motherboards and a couple proprietary designs. This accounts for a
> very limited total number of users and as such isn't worth breaking
> working concepts or compatibility. I'm sorry to insist but I fear that
> what you (and Brian) are trying to implement would belong to Linux 2.6,
> not 2.4.
> 

Recall from our IRC discussion that you would work on xxxx_4882 and submit the patches,
I would work on Brian's implementation. Don't be 'suspicious' :)

My brief summary is that Brian's implementation separates the generic part
of bus muxing into a bus algorithm driver (i2c-virtual) and puts the chip-specific
part into a combination bus adapter driver and chip driver (pca954x).
This parallels i2c-algo-bit and the numerous big-banging bus adapters,
and fits well into our architecture.

The code I got from Brian was for 2.4. So that's where I put it.
Not sure what you are "insisting" - what's wrong with getting it working
on 2.4 first before porting to 2.6?

Anyway, happy to discuss further on IRC if you like, let me know.
mds

Call for 2.9.0

[Jean Delvare]

> > Strange order, huh?
>
> I thought I did exactly as we discussed on IRC a few weeks ago.
> You didn't want i2c-core changes at that time because you were working on
> 2.9.0.
> I said I'd work on the i2c-virtual code received from Brian.
> I checked it in to sensors for review and comment.
> I thought that's what we agreed to.

Hmm, that's possible. I have to say I have a very bad memory and I
don't remember exactly. I believe you :)

> > Irk! How exactly is i2c-core supposed to know i2c_virt_parent when it's
> > defined by lm_sensors? How is it even supposed to know about
> > CONFIG_I2C_VIRTUAL (and what is CONFIG_I2C_VIRTUAL_MODULE?)? Looks like
> > a circular dependency issue to me.
>
> i2c-core needs to include i2c-virtual.h to get the i2c_virt_parent()
> definition - but that wasn't in the patch I posted.

Getting the definition is only one part of the problem. Modules
dependencies is another, and subsystem design is yet a third one - this
is the part that gets me worried. What you propose needs either
duplicating the i2c-vitrual.h file, or making i2c's compilation
dependent on lm_sensors. Neither is acceptable IMHO. And the fact that
i2c-core will depend on i2c-virtual which is supposedly an algorithm is
strange too - it always has been the other way around so far.

The core should not need to know anything about who will be using it. The
core exports an interface, other drivers use it, this is how things have
worked to date and I see little reason this should change.

> What Brian discovered is that an i2c bus mux implementation requires a
> nolock version of some functions. Think about how the bootstrap works:
>  Bus gets added
>  Mux chip found
>  Sub busses get added (but can't because lock still held - hang)

I understand (although I did not dive deep enough into the code yet to
see why the lock is held for so long).

> So that's what the (first half of) i2c-core patch does. Get rid of the
> leading '__', rename to xxx_nolock, and export them so that the virtual
> driver can implement the bootstrap.

This sounds fundamentally wrong to me now that I see what it is. Sorry
for not noticing this before when we discussed it. Seems like I am
unable to see what's wrong until I read actual patches to the i2c-core
:(

> It's not a big change. Maybe there's a way to avoid it, though... I don't
> know.

It IS a big change. OK, it doesn't break the compatibility with Linux
2.4 (which is great since it really wouldn't have happened). However,
exporting functions that only a limited number of drivers should call
without the possibility to check that others actually don't is
potentially dangerous. Also, the locks were there for a reason and
bypassing them doesn't sound too good.

As I understand it, the reason why the "nolock" version are needed is
because the adapters' lock is still held while adding clients to the
new adapter. Why is that? I see no reason. The second deadlock is
obviously for the chips' lock and the reason why the lock is still held
is more obvious this time.

I really need to take a closer look at the current implementation and see
how Brian's model fits in (or doesn't). I feel that it is not correct
but my criticism and fear will be of no use if I do not understand the
whole picture before going on.

Just one thought though, the whole locking issue is related to the fact
that the pca954x chips would be handled as regular chip drivers with
detection and  auto-attach to all busses. Do we really want to do that?
Multiplexers are NOT standard chips, they are hard to detect, they
don't export anything to userspace and behave like bus drivers if I
understood correctly. Maybe we can get rid of the locking issue by
simply handling these chips in the different way they deserve (i.e.
implicitely load them *after* the bus driver has been loaded).

> It could have gone either place, what's the difference?

lm_sensors is supposedly a package for hardware monitoring drivers and
tools, i2c is for the i2c subsystem. That's quite different, although
both have been mixed so far with sometimes no apparent logic.

The idea is that lm_sensors builds on top of the i2c subsystem. The way
you are implementing things, someone who wants to do any kind of
multiplexing will have to get lm_sensors too for no obvious reason other
than randomly placed files.

> You were in the middle of i2c changes so I put it in sensors. Again, I
> thought this was what we agreed to - I wouldn't make any i2c changes.
> We can move i2c-virtual.c to i2c if you want.

I think we'll end up doing that, yes. Not yet though, since as you
noticed, releasing i2c 2.9.0 has higher priority.

What I agreed on was that you would hold up before committing the changes
to i2c. What I don't agree on now is the way you divided the code
between i2c and lm_sensors. This is different. Again, sorry for not
looking into brian's code before. I'm doing my best with the time I
have - we all do, right?

> pca954x.c can't move because it's a chip driver.

I don't see how this prevents it from being part of i2c. The fact that
we never did it before doesn't mean we cannot do it now. As said above,
these chips are nowhere similar to the other ones.

>Your other questions:
> - the implentation at the i2c-core level is simply the patch I posted
>   yesterday

But you said that there were a "second part". Simply some header
changes?

> - The code in sensors CVS _is_ the equivalent of i2c-amd756-4882. The
>   "real-world use case" is "modprobe i2c-amd756; modprobe i2c-virtual;
>   modprobe pca9556 [params]", where pca9556 looks alot like pca954x.

I really need to read the code in whole. I don't get how it works. At
any rate i2c-amd756-4882 is board-specific, while Brian's
implementation is generic, so it cannot be rigourosly similar.

> Recall from our IRC discussion that you would work on xxxx_4882 and submit
> the patches, I would work on Brian's implementation. Don't be 'suspicious'
> :)

Please don't take it bad or personnal or anything. I am not trying to
prevent you from including i2c-virtual nor am I trying to protect the
choice of implementation I made for the S4882 - I said from the very
beginning that this was not necessarily meant as a definitive solution.

I am trying to protect the i2c subsystem though, admittedly. Just
remember that I am the one who maintained the i2c-2.8.x compatibility
patches for maybe 8 months, prepared patches for Marcelo and saw them
rejected in bulk, and then very recently reverted all changes to i2c
that had been interrupted halfway (by KM) to get compatibility back with
Linux 2.4. Now that I am done with that, nobody is going to break i2c
again, believe me.

> My brief summary is that Brian's implementation separates the generic part
> of bus muxing into a bus algorithm driver (i2c-virtual) and puts the
> chip-specific part into a combination bus adapter driver and chip driver
> (pca954x).
> This parallels i2c-algo-bit and the numerous big-banging bus adapters,
> and fits well into our architecture.

My short experience shows that the chip-specific part is very thin and
that we are probably not saving much by doing that (especially since
every known board with multiplexing uses a different chip so far),
contrary to i2c-algo-bit (and the adapter and chip independency we have
too). That said the idea of a generic solution to the multiplexing cases
still sounds good - much better than having to manually add support for
each one, I guess.

> The code I got from Brian was for 2.4. So that's where I put it.
> Not sure what you are "insisting" - what's wrong with getting it working
> on 2.4 first before porting to 2.6?

What will you do when you port your implementation to 2.6 and Greg
rejects it, and you have to do it completely differently to get it
accepted? 2.6 is the future of the Linux kernel and it's much more
logical to get things working there first, then port them back to 2.4 on
the same model. 2.6 also receives much more review tahn what we do on
our own side for lm_sensors and i2c/CVS. Anyway this is a side issue.

> Anyway, happy to discuss further on IRC if you like, let me know.

Certainly, but not before I have had time to read Brian's code and
documentation in whole. I am probably not going to be useful at all
until I've done that.

Thanks,
--
Jean Delvare

Call for 2.9.0

[Mark M. Hoffman]

Hi Mark:

(cc'ed Brian also)

* Mark D. Studebaker <mds4@verizon.net> [2004-12-09 11:01:36 -0500]:
> What Brian discovered is that an i2c bus mux implementation requires a 
> nolock version
> of some functions. Think about how the bootstrap works:
> 	Bus gets added
> 	Mux chip found
> 	Sub busses get added (but can't because lock still held - hang)
> So that's what the (first half of) i2c-core patch does. Get rid of the 
> leading '__', rename to xxx_nolock,
> and export them so that the virtual driver can implement the bootstrap.
> 
> It's not a big change. Maybe there's a way to avoid it, though... I don't 
> know.

Well... why can't you do the sub-bus creation in pca954x_attach_adapter()
(after the call to i2c_detect) ?  This gets rid of all the locking problems,
and IMHO makes more sense w.r.t. the respective function names anyway.

Regards,

-- 
Mark M. Hoffman
mhoffman@lightlink.com

Call for 2.9.0

[Jean Delvare]

Hi all,

Can we schedule a release for next week?

Thanks,
-- 
Jean Delvare
http://khali.linux-fr.org/

Call for 2.9.0

[Jean Delvare]

Quoting myself:

> Can we schedule a release for next week?

I just verified compatibility with old kernels back to 2.4.10, and
commited a couple trivial fixes for this. 2.4.9 is no longer supported,
as it would require more work than is worth (most notably because
MODULE_LICENSE doesn't exist back there).

I also reviewed the documentation and updated it where needed, most
notably to reflect the fact that 2.4.10 is now the oldest supported
kernel, and also to discard references to the now gone bttv
compatibility issue.

I think we are ready for a release. Libsensors version will need a bump,
not exactly sure if we would number it 3.0.7 or 3.1.0.

I will be mostly away from the Internet for the next few days. Feel free
to release while I am gone unless a problem arise.

Thanks,
-- 
Jean Delvare
http://khali.linux-fr.org/

Call for 2.9.0

[Mark Studebaker]

agreed. I bumped libsensors.
Phil, at your convenience....
merry christmas.
mds

Jean Delvare wrote:
> Quoting myself:
> 
> 
>>Can we schedule a release for next week?
> 
> 
> I just verified compatibility with old kernels back to 2.4.10, and
> commited a couple trivial fixes for this. 2.4.9 is no longer supported,
> as it would require more work than is worth (most notably because
> MODULE_LICENSE doesn't exist back there).
> 
> I also reviewed the documentation and updated it where needed, most
> notably to reflect the fact that 2.4.10 is now the oldest supported
> kernel, and also to discard references to the now gone bttv
> compatibility issue.
> 
> I think we are ready for a release. Libsensors version will need a bump,
> not exactly sure if we would number it 3.0.7 or 3.1.0.
> 
> I will be mostly away from the Internet for the next few days. Feel free
> to release while I am gone unless a problem arise.
> 
> Thanks,

Call for 2.9.0

[Philip Edelbrock]

OK, I just got back from a family gathering.  I'll release tomorrow 
unless there is some urgency pointed out to me.


Phil

On Dec 24, 2004, at 7:55 AM, Mark Studebaker wrote:

> agreed. I bumped libsensors.
> Phil, at your convenience....
> merry christmas.
> mds
>
> Jean Delvare wrote:
>> Quoting myself:
>>> Can we schedule a release for next week?
>> I just verified compatibility with old kernels back to 2.4.10, and
>> commited a couple trivial fixes for this. 2.4.9 is no longer 
>> supported,
>> as it would require more work than is worth (most notably because
>> MODULE_LICENSE doesn't exist back there).
>> I also reviewed the documentation and updated it where needed, most
>> notably to reflect the fact that 2.4.10 is now the oldest supported
>> kernel, and also to discard references to the now gone bttv
>> compatibility issue.
>> I think we are ready for a release. Libsensors version will need a 
>> bump,
>> not exactly sure if we would number it 3.0.7 or 3.1.0.
>> I will be mostly away from the Internet for the next few days. Feel 
>> free
>> to release while I am gone unless a problem arise.
>> Thanks,
>

Call for 2.9.0

[Jean Delvare]

Quoting myself (again):

> I just verified compatibility with old kernels back to 2.4.10, and
> commited a couple trivial fixes for this. 2.4.9 is no longer
> supported, as it would require more work than is worth (most notably
> because MODULE_LICENSE doesn't exist back there).

I was not quite correct here. MODULE_LICENSE is properly handled from a
long time through a quirk in i2c.h. i2c 2.9.0 will actually be
2.4.9-compatible. However, lm_sensors 2.0 won't and we probably don't
want it to be. 2.4.9 not only lacks MODULE_LICENSE but also snprintf,
min_t/max_t and a couple other functions/macros used in various
lm_sensors drivers. I see little point in supporting 2.4.9 in i2c and
only 2.4.10 in lm_sensors, which is why I believe we can happily go with
2.4.10 for both. Only a fool would use such old kernels today anyway.

Thanks,
-- 
Jean Delvare
http://khali.linux-fr.org/

Call for 2.9.0

[Philip Pokorny]

Unless these same limitations apply to a particular series of kernel 
releases from Red Hat.  Like it or not, there are comercial software 
packages that still are only supported on relatively ancient distro's 
like Red Hat 7.1 and 7.3.

The good news is that the last Red Hat 7.x errata kernel was pretty 
recent.  Let me check...

Hmmm..  OK...

Red Hat 7.1 was released with a 2.4.9 kernel base but the most recent 
errata kernel I see is 2.4.20-28.7
Red Hat 7.3 was released with a 2.4.18 kernel base and the most recent 
errata kernel is 2.4.20-28.7

Red Hat 8, 9 and so on are of course more recent.

Unfortunately, Red Hat 2.1 Advanced Server uses a derivative of the 7.1 
kernel: 2.4.9-e.24 (in Update 2).

So if we drop 2.4.9, then I think we need to test the Red Hat Advanced 
Server kernel.  (Which I will volunteer to do...)  Depending on the 
result of that test, I would suggest that we mention what distro kernels 
are not supported (*initial* 7.1 kernel, etc.).

:v)

Jean Delvare wrote:

>Quoting myself (again):
>
>  
>
>>I just verified compatibility with old kernels back to 2.4.10, and
>>commited a couple trivial fixes for this. 2.4.9 is no longer
>>supported, as it would require more work than is worth (most notably
>>because MODULE_LICENSE doesn't exist back there).
>>    
>>
>
>I was not quite correct here. MODULE_LICENSE is properly handled from a
>long time through a quirk in i2c.h. i2c 2.9.0 will actually be
>2.4.9-compatible. However, lm_sensors 2.0 won't and we probably don't
>want it to be. 2.4.9 not only lacks MODULE_LICENSE but also snprintf,
>min_t/max_t and a couple other functions/macros used in various
>lm_sensors drivers. I see little point in supporting 2.4.9 in i2c and
>only 2.4.10 in lm_sensors, which is why I believe we can happily go with
>2.4.10 for both. Only a fool would use such old kernels today anyway.
>
>Thanks,
>  
>

Call for 2.9.0

[Jean Delvare]

Hi Philip,

> Unfortunately, Red Hat 2.1 Advanced Server uses a derivative of the
> 7.1  kernel: 2.4.9-e.24 (in Update 2).
> 
> So if we drop 2.4.9, then I think we need to test the Red Hat
> Advanced Server kernel.  (Which I will volunteer to do...)

I don't think we *need* to. You might want to, but that's different.

It is Red Hat's decision to stick to a 2.4.9 kernel. This means that
they are probably putting a lot of efforts in porting tons of fixes back
to it. Then they can do the same with lm_sensors, i.e. stick to 2.7.0
and backport whatever they like. This is certainly what they do already.

Frankly, who with a 2.4.9 kernel would really need what is in lm_sensors
2.9.0 and wasn't in 2.7.0, and dare to complain that lm_sensors 2.9.0
doesn't work?

> Depending on the result of that test, I would suggest that we mention
> what distro kernels are not supported (*initial* 7.1 kernel, etc.).

We support vanilla kernels, not vendor ones (Red Hat or others) and have
always claimed so. We are not going to list all (un)supported vendor
kernels, as such a list would obviously be unmaintainable.

Please keep in mind that i2c & lm_sensors 2.8.x were not compatible with
any kernel older than 2.4.17 (although we claimed 2.4.9 compatibility),
and nobody complained. This is certainly a good proof that people with
these old kernels are still using lm_sensors 2.7.0 and are happy with
that.

Thanks,
-- 
Jean Delvare
http://khali.linux-fr.org/