Re: Fixing the lm-sensors/i2c mess
On Wed, Dec 31, 2003 at 12:39:39AM -0500, Nathanael Nerode wrote:
> The key points are this:
> * i2c underwent a major incompatible change. The new version is
> required by lm-sensors 2.8.x. The old version is present in the
> upstream kernel tree 2.4 i2c modules. The new version is in the 2.6
> kernel tree, and in a separate i2c upstream package for 2.4 versions,
> and in a patch to the 2.4.23 and 2.4.22 kernel tree.
The 2.4 version only has a very small part of the 2.6 version, so
I would rather call it some immediate step..
> Lots of people have been getting crashes because the old i2c modules
> will override the new modules when both are present, and people's kernel
> packages often have the old modules installed.
There real problem is that the new modules changed the API in an
incompatible way. This could be easily fixed by adding the old methods
back, what about escalating this back to upstream? This affects a lot
more than just Debian.
> It looks to me like this is what needs to be done to get this stuff in
> good shape for sarge; I'm not sure in what order.
>
> * Herbert Xu: Apply the upstream patches in
> http://www.ensicaen.ismra.fr/~delvare/devel/i2c/
> to the kernel-source-2.4.22, and kernel-source-2.4.23 packages.
This totally breaks the i2c API is not an option for a 2.4 package.
Please make sure the mod_inc_use_count / mod_dec_use_count methods
are still present in the i2c function vectors and at the same problem
as before. Then most of the problems will just magically disappear.
Adding the 'new' i2c code will just trade breakade with the lm_sensors
modules vs breakage with other i2c modules.
> Alternately (and worse) disable the i2c modules from the upstream kernel
> tree (and all the modules depending on them) by default, allowing the
> modules from i2c-source to install cleanly without running into kernel
> versions of the i2c modules.
That's clearly not an option. i2c is used for much more than just
thermal monitoring, and there's lots of drivers in the kernel tree that
require it, e.g. sound support on pmac hardware.
Reply to: