KERNELVERSION=2.6.12-something make

attached patches allow making with setting in environment.

it apparently is effective only right after make clean, but dependencies are remembered in all the foo.d files

Separately, Ive been trying to hack around my lack of include/linux/modversions.h, which is not present in the 2.6.12, 13-rc trees that Ive built

Ive tried turning off CONFIG_MODVERSIONS,
despite some ifdefs in some of the code that suggest it shoul help, I get almost nowhere doing so.

is modversions.h a synthesized file (written based upon config) ? is it a holdover from earlier kernel releases ?

-------------- next part --------------

@@ -28,7 +28,7 @@
 
 # The currently running kernel version. This is used right below to
 # determine where the kernel sources can be found.
-KERNELVERSION := $(shell uname -r)
+KERNELVERSION ?= $(shell uname -r)
 
 # The location of linux itself. This is used to find the kernel headers
 # and other things.

-------------- next part --------------

@@ -25,7 +25,7 @@
 
 # The currently running kernel version. This is used right below to
 # determine where the kernel sources can be found.
-KERNELVERSION := $(shell uname -r)
+KERNELVERSION ?= $(shell uname -r)
 
 # The location of linux itself. This is used to find the kernel headers
 # and other things.

Hi Jim,

I suspect that you are trying to build the kernel modules of lm_sensors with a 2.6 kernel. No surprise it doesn't work, it is not supposed to. With a 2.6 kernel, the only part of lm_sensors you are interested in is the user-space tools, which are built with "make user" and installed with "make user_install". Don't use "make" nor "make install".

--
Jean Delvare

Hi again Jim,

Oh, BTW, I don't think this is needed. If you want to compile i2c or lm_sensors for a different kernel than the running one, use:
make LINUX=/path/to/linux

Works fine for me.

Note that this is only needed for Linux 2.4 kernels anyway, which doesn't seem to be your case.

--
Jean Delvare

true. when I do make user, no kernel headers are used, so no FC-3 stuff fouls the nest.

FWIW: I just tried to stuff this into Makefile, to automate the clue-stick you poked me with:

ifneq (,$(findstring 2.6 , $(KERNELVERSION)))

    ifneq (,$(findstring 'user', $(MAKECMDGOALS)))
        $(error 'only user* targets needed/supported for 2.6 builds')
    endif

endif

obviously, it didnt work, or Id have sent a patch.
Can you fit it in the proper place, or advize where it belongs ?

[jimc@harpo lm_sensors2]$ make
Makefile:91: *** For 2.6 kernels and later, use "make user". Stop. [jimc@harpo lm_sensors2]$ make install
Makefile:94: *** For 2.6 kernels and later, use "make user_install". Stop.

ie, works for me.
At first I didnt like the extra noise/Stop, but changed my mind. It has better chance of standing out in a gentoo-like full system build. Someday, someone will ask that the makefile just does what the user should have asked for ;-)

So, patch attached, which adds a # comment, so that when clueful users look at the line in the makefile, they'll know why its an error. Also replaced leading spaces with tabs, to keep emacs makefile mode from interrogating me on saves (not needed for making, but saves annoyance).

heh. My pleasure.
For what Im paying you, you shouldn't have to listen to me bitch. Bad patches may contain good ideas, Im glad you are willing to separate the wheat from the chaff, its certainly meaningful encouragement. Get *great* mileage on bad gas !
Honey attracts bears better than a skunk does.
Curiously, so does a rotting carcass.
(ok, enough slogans, before I get silly).

In the half-baked ideas dept ( while youre still enjoying my attitude) ..

I was poking around to see if could grok the sysfs api support that would allow replacing the long lists of

                device_create_file(&new_client->dev, &dev_attr_inX_input);

with something like:

    for(i=0; i<vpoints_max; i++) {
                device_create_file(&new_client->dev, &dev_attr_in[i].in);
                device_create_file(&new_client->dev, &dev_attr_in[i].max);
                device_create_file(&new_client->dev, &dev_attr_in[i].min);
    }

looking at it again now, it appears to hinge upon doing something clever with DEVICE_ATTR, and unwinding some of the large-ish macros. ... and a bunch of stuff I havent yet understood.

..I did say half-baked ;-)

This should have been in another thread, feel free to change the subject if you want .. (sending) no wait, too late..

ahh, umm, here it is. I hate it when I do that. which is too often.

-------------- next part --------------

@@ -86,6 +86,16 @@
 #   /lib/modules/2.4.29
 MODPREF := /lib/modules/$(shell $(CC) -I$(LINUX_HEADERS) -E etc/config.c | grep uts_release |cut -f 2 -d'"')
 
+# protect 2.6 users from misusing makefile, and getting confusing results
+ifeq (,$(findstring /2.4., $(MODPREF)))
+    ifeq (, $(MAKECMDGOALS))
+        $(error For 2.6 kernels and later, use "make user")
+    endif
+    ifeq (install, $(MAKECMDGOALS))
+        $(error For 2.6 kernels and later, use "make user_install")
+    endif
+endif
+
 # This is the directory where sensors.conf will be installed, if no other
 # configuration file is found
 ETCDIR := /etc

@@ -310,7 +320,7 @@
 	$(RM) lm_sensors-*
 
 user_uninstall::
-	
+
 uninstall :: user_uninstall
 	@echo "*** Note:"
 	@echo "***  * Kernel modules were not uninstalled."

@@ -409,7 +419,7 @@
 
 %.d: %.c $(LINUX)/.config
 	$(CC) -M -MG $(MODCPPFLAGS) $(MODCFLAGS) $< | \
-       	$(SED) -e 's@^\(.*\)\.o:@$*.d $*.o: Makefile '`dirname $*.d`/Module.mk' @' > $@
+	$(SED) -e 's@^\(.*\)\.o:@$*.d $*.o: Makefile '`dirname $*.d`/Module.mk' @' > $@
 
 
 

@@ -419,7 +429,7 @@
 
 %.rd: %.c
 	$(CC) -M -MG $(PROGCPPFLAGS) $(PROGCFLAGS) $< | \
-       	$(SED) -e 's@^\(.*\)\.o:@$*.rd $*.ro: Makefile '`dirname $*.rd`/Module.mk' @' > $@
+	$(SED) -e 's@^\(.*\)\.o:@$*.rd $*.ro: Makefile '`dirname $*.rd`/Module.mk' @' > $@
 
 
 %: %.ro

@@ -432,7 +442,7 @@
 
 %.ad: %.c
 	$(CC) -M -MG $(ARCPPFLAGS) $(ARCFLAGS) $< | \
-       	$(SED) -e 's@^\(.*\)\.o:@$*.ad $*.ao: Makefile '`dirname $*.ad`/Module.mk' @' > $@
+	$(SED) -e 's@^\(.*\)\.o:@$*.ad $*.ao: Makefile '`dirname $*.ad`/Module.mk' @' > $@
 
 
 # .lo files are used for shared libraries

@@ -441,7 +451,7 @@
 
 %.ld: %.c
 	$(CC) -M -MG $(LIBCPPFLAGS) $(LIBCFLAGS) $< | \
-       	$(SED) -e 's@^\(.*\)\.o:@$*.ld $*.lo: Makefile '`dirname $*.ld`/Module.mk' @' > $@
+	$(SED) -e 's@^\(.*\)\.o:@$*.ld $*.lo: Makefile '`dirname $*.ld`/Module.mk' @' > $@
 
 
 # Flex and Bison

OK, applied, thanks.

For next time, please remember that sending separate patches for separate things is generally better, as one part may be OK and the other one may not be or may need discussion.

Thanks,

Jean Delvare

Hi Jim,

You're correct, things could be done in a more efficient way. There is a sysfs attribute group API which could be used, or we could use for() loops like you proposed (and I proposed before you [1]). But you also have to remember that some drivers will not create all sysfs files depending on which chip they detected and what features these chips may have disabled.

So it's a tricky point, and decisions should be taken on a by-driver basis. And you better know that driver pretty well before you do.

[1] http://lkml.org/lkml/2005/5/19/140

Jean Delvare