From: mds@paradyne.com (Mark D. Studebaker)
To: lm-sensors@vger.kernel.org
Subject: lm_sensors2 Makefile
Date: Thu, 19 May 2005 06:23:40 +0000 [thread overview]
Message-ID: <3DA75EB7.3083705@paradyne.com> (raw)
In-Reply-To: <1033131073.3d945441d6d95@imp.free.fr>
Khali's point about having i2c and lm_sensors be the same is well taken.
I don't really see why the "default" kernel would be different than the
"running"
kernel. But I think that /lib/modules/uname-r/build is more likely to be
correct
than /usr/src/linux and so is a better choice.
That's why I liked the patch. But just my opinion.
Dave, we've been searching for someone to generate current RPM's and
improve
our RPM support for quite a while. Be glad to have you do it if you are
willing.
mds
Dave Johnson wrote:
>
> At this point, I'm not fond of either approach... they each work better
> in some situations than in others. If someone familiar with autoconf
> and the like would be able to "autoconfiscate" the lm_sensors build, the
> choice of which kernel to reference could be parametrized. I'm thinking
> somewhere along the lines of "--use-running-kernel" and/or "--with-linux=...",
> where the default would be /usr/src/linux[-2.4], running-kernel would be
> /lib/modules/$(shell uname -r)/build, and --with-linux= would be specific
> where the kernel sources are. It's already possible to handle the default
> and --with-linux just by putting "LINUX=/blah/de/blah" on the make command
> line, but the running-kernel (or running-linux for consistency) would be
> a useful shorthand.
>
> A good generic rpm lm_sensors2.spec file would also be nice. We're using
> the NPACI Rocks cluster software collection, and for kernel-dependent
> modules, the source rpm files found in specific SRPMS directories are
> automatically rebuilt when a cluster slave node is reinstalled. I'd
> like to be able to do this with lm_sensors as well. Autoconf would be
> nice but not necessary in this case, since environment variables can be
> set up in the .spec file to override the defaults in the Makefile.
>
> Right now, my highest priority is getting cluster nodes up and running.
> But if I get to it before anyone else, I might take a stab at the .spec file.
> We have two clusters that are being converted to Rocks, and three new clusters
> ready or nearly ready to have the Rocks software installed from scratch.
>
> -- ddj
>
> On Fri, Sep 27, 2002 at 02:51:13PM +0200, Khali wrote:
> >
> > > Modified Files:
> > > Makefile
> > > Log Message:
> > > (mds) take LINUX from /lib/modules/x.x.x/build; patch from
> > > Dave Johnson <ddj@cascv.brown.edu>
> >
> > Hmmm...
> > This isn't that clear to me.
> >
> > While the new way (/lib/modules/$(shell uname -r)/build) ensures we are
> > compiling the modules for the current kernel, the old way (/usr/src/linux)
> > allowed one to compile the modules for the default kernel, whatever the current
> > kernel is.
> >
> > As far as I'm concerned, I prefer the old way. I happen to change kernel
> > versions quite often (testing both ACPI and CPUFreq on my system) and have to
> > reconfigure and reinstall i2c and lm_sensors everytime. Using /usr/src/linux as
> > the default, I am able to do so *before* I actually reboot on the new kernel.
> > With the new way, I would have to do the same *after* the reboot.
> >
> > I would be pleased to listen to arguments in favor of the new way.
> >
> > Anyway, whatever we decide, I think that we should do the same in i2c and
> > lm_sensors (which isn't the case right now).
> >
> > Later,
> > Khali
next prev parent reply other threads:[~2005-05-19 6:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-19 6:23 lm_sensors2 Makefile Khali
2005-05-19 6:23 ` Dave Johnson
2005-05-19 6:23 ` Mark D. Studebaker [this message]
2005-05-19 6:24 ` Jean Delvare
2005-05-19 6:24 ` Jean Delvare
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3DA75EB7.3083705@paradyne.com \
--to=mds@paradyne.com \
--cc=lm-sensors@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.