[lm-sensors] [patch] KERNELVERSION=2.6.12-something make

[lm-sensors] [patch] KERNELVERSION=2.6.12-something make

[Jim Cromie]

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 --------------
--- lm_sensors2/Makefile.~1.96.~	2005-07-21 18:54:47.000000000 -0600
+++ lm_sensors2/Makefile	2005-07-21 18:55:45.000000000 -0600
@@ -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 --------------
--- i2c/Makefile.~1.38.~	2005-03-19 04:10:34.000000000 -0700
+++ i2c/Makefile	2005-07-21 18:37:06.000000000 -0600
@@ -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.

[lm-sensors] [patch] KERNELVERSION=2.6.12-something make

[Jean Delvare]

Hi Jim,

On 2005-07-22, Jim Cromie wrote:

> 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 ?

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

[lm-sensors] [patch] KERNELVERSION=2.6.12-something make

[Jean Delvare]

Hi again Jim,

On 2005-07-22, Jim Cromie wrote:
> attached patches allow making with setting in environment.

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

[lm-sensors] [patch] KERNELVERSION=2.6.12-something make

[Jim Cromie]

Jean Delvare wrote:

>Hi again Jim,
>
>On 2005-07-22, Jim Cromie wrote:
>  
>
>>attached patches allow making with setting in environment.
>>    
>>
>
>Note that this is only needed for Linux 2.4 kernels anyway, which
>doesn't seem to be your case.
>
>  
>
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 ?

>--
>Jean Delvare
>
>  
>

[lm-sensors] [patch] KERNELVERSION=2.6.12-something make

[Jean Delvare]

Hi Jim,

> 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 ?

The following, derived from yours, works for me:

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

I've added it right after the line which computes $(MODPREF). Please
give it a try and tell me what you think. I might commit it to CVS if
nobody objects. I might also add something similar to the i2c package.

BTW, Jim, I'd like to add that I very much enjoy your attitude of
sending patches to help us fix things rather that just complaining that
things don't work. Even if the patches end up not being needed or
correct, don't stop! :) This is always a good base to start with.

-- 
Jean Delvare

[lm-sensors] [patch] KERNELVERSION=2.6.12-something make

[Jim Cromie]

Jean Delvare wrote:

>Hi Jim,
>
>  
>
>>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 ?
>>    
>>
>
>The following, derived from yours, works for me:
>
>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
>
>I've added it right after the line which computes $(MODPREF). Please
>give it a try and tell me what you think. I might commit it to CVS if
>nobody objects. I might also add something similar to the i2c package.
>
>  
>
[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).

>BTW, Jim, I'd like to add that I very much enjoy your attitude of
>sending patches to help us fix things rather that just complaining that
>things don't work. Even if the patches end up not being needed or
>correct, don't stop! :) This is always a good base to start with.
>
>  
>
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..

[lm-sensors] [patch] KERNELVERSION=2.6.12-something make

[Jim Cromie]

Jim Cromie wrote:

>
> 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).
>
ahh, umm, here it is.  I hate it when I do that. which is too often.


-------------- next part --------------
--- lm_sensors2/Makefile.~1.96.~	2005-07-22 14:56:59.000000000 -0600
+++ lm_sensors2/Makefile	2005-07-22 15:09:16.000000000 -0600
@@ -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

[lm-sensors] [patch] KERNELVERSION=2.6.12-something make

[Jean Delvare]

> > 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).
>
> ahh, umm, here it is.  I hate it when I do that. which is too often.

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

[lm-sensors] [patch] KERNELVERSION=2.6.12-something make

[Jean Delvare]

Hi Jim,

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

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