All of lore.kernel.org
 help / color / mirror / Atom feed
From: khali@linux-fr.org (Jean Delvare)
To: lm-sensors@vger.kernel.org
Subject: W83627HF SuperIO support in lm_sensors
Date: Thu, 19 May 2005 06:24:20 +0000	[thread overview]
Message-ID: <20030930195645.29a8f9d8.khali@linux-fr.org> (raw)
In-Reply-To: <20030929180436.GB1779@pua.nirvana>


> > If you want more drivers, either tweak the FILES and Config.in files
> > in mkpatch, or build the modules directly in the lm_sensors
> > directory instead of patching the kernel.
> 
> What do you think is better for an rpm (and what is better supported
> by you in general)? I checked the first way and it would require
> someone providing me with the changes, and these would have to be
> synced with the next lm_sensors release.
>
> The second proposal is something I could do propably without
> assistance (building kernel modules), but this would have to wait for
> some time (a couple of weeks), as it means ripping lm_sensors out of
> the atrpms kernels and providing it seperately, and also rebuilding
> and redistributing all further atrpms kernel modules.

I would use solution 2. This is what I do as a user. It doesn't change a
thing as far as packaging is concerned. You may build the modules inside
the lm_sensors tree rather than inside the kernel tree, they still end
up in /lib/modules, where they have to be. The only difference is that
you can't choose which module you want to install with solution 2, but
being packaging a kernel, you obviously don't want to exclude any driver
anyway.

That said, I think that we could add many drivers (if not all) to the
list of "considered stable" drivers. I can't think of any of our drivers
that may cause serious problems [1] so there is no real reason not to
include them all.
> 
> On Tue, Sep 30, 2003 at 10:40:20AM +0200, Alfredo Milani-Comparetti
> wrote:

Aha, you're the almico.com guy. Nice to see you here actually, I did not
know you were using Linux too :)

> > I see :-)
> > Anyway: since yours is a kernel recompiled for those who "know what
> > they're doing" and since setting up lm_sensors needs some knowledge,
> > I think it would be nice to include all those modules in your
> > distribution. Consider that sensors-detect script already knows
> > which modules are dangerous and which ones are not and acts
> > accordingly. Just a suggestion. Thank you for your time :-)
> 
> OK, sounds reasonable, what do you think, Jean?

Yes, let's go. Either you switch so solution 2, or you wait for us to
update our list, if nobody on the list objects it, of course.



[1] Actually, the adm1021 driver seems to cause much trouble these days,
for an unknown reason, and the i2c-piix4 used to cause trouble to
Thinkpad users - and they *are* both in the list of stable drivers.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

  reply	other threads:[~2005-05-19  6:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-19  6:24 W83627HF SuperIO support in lm_sensors Axel Thimm
2005-05-19  6:24 ` Jean Delvare [this message]
2005-05-19  6:24 ` Axel Thimm
2005-05-19  6:24 ` Jean Delvare
2005-05-19  6:24 ` Axel Thimm
2005-05-19  6:24 ` Alfredo Milani-Comparetti

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=20030930195645.29a8f9d8.khali@linux-fr.org \
    --to=khali@linux-fr.org \
    --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.