Hi Axel, > > 1* Doesn't include our dmi_scan. > > 2* Patches the kernel one. > > > > 1 is trivial, and 2 should not be too hard. > > I'd like to reroll RHL & FC kernels (2.4.20 and 2.4.22 based), and fix > also the dmi_scan issue. Has any of the above suggestions found its > way into i2c CVS (I'd love a > http://www.ensicaen.ismra.fr/~delvare/devel/i2c/ > patch :)? No, I have to admit I had completely forgotten about this issue and nothing was done. I just took a look at the files and I think I missed a step in my first plan. The problem is that our dmi_scan module exports the whole DMI information and leaves it do i2c-piix4 to compare the strings, while the kernel's dmi_scan, once patched, would preferably export a simple flag. So step 1 is to make our own dmi_scan compute and export that flag instead of the whole data, and change i2c-piix4 so that it always looks for the flag and doesn't try to access the whole data. I just did that, proposed patch to lm_sensors2 attached. I do *not* want to apply it right now since we're about to release and this is a sensible change. You can still apply it before building your RPMs. Step 2 is that lm_sensors2's mkpatch shouldn't include dmi_scan.c/.h. Easy, patch attached. Step 3 is that lm_sensors2's mkpatch should include a patch to arch/i386/kernel/dmi_scan.c. This is the hardest part. Even before changing mkpatch so that it is able to dynamically create the patch (it must work with every kernel version), we have to make sure that we agree on what has to be done exactly. Attached is my proposal for a kernel 2.4.22. It looks like we have to patch i386_ksyms.c as well. Please note that these changes do not belong to the i2c package. For this reason, I don't think it would be a good idea to include them to the i2c patch, as you once suggested IIRC. This would make things even more complex in the end. > Or should I use one of the less favoured, but easier (for me) to > implement solutions (renaming files)? Well, I invite you to test the patches attached, and tell us how it is working for you. Note that I didn't test anything myself (except that it still compiles). If it works OK and nobody objects, after 2.8.6 has been released, I'll apply the changes our CVS repository and hack mkpatch.pl so that it learns how to generate the kernel patch to dmi_scan regardless of the kernel version. Thanks. -- Jean Delvare http://www.ensicaen.ismra.fr/~delvare/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lm_sensors2-dmi_scan.diff Url: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20040404/3028e73c/attachment.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lm_sensors2-mkpatch.diff Url: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20040404/3028e73c/attachment-0001.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: linux-2.4.22-dmi_scan.diff Url: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20040404/3028e73c/attachment-0002.pl
