From: Jean Delvare <khali@linux-fr.org>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] Proposal
Date: Mon, 18 Jun 2007 18:31:33 +0000 [thread overview]
Message-ID: <20070618203133.4f14831c@hyperion.delvare> (raw)
In-Reply-To: <200704081630.17151.hjk@linutronix.de>
Hi Mark,
On Sat, 16 Jun 2007 11:14:36 -0400, Mark M. Hoffman wrote:
> Finally, back to the thread that resulted in change of maintainers, but not
> yet any merged code. ;)
Naah, it was a _coincidence_.
> There is another way to look at it: the uguru3 is not a single chip, it is a
> *family* of chips. With that model, we would end up with a compromise between
> your positions that has precedent in other drivers.
I can't really think of any precedent in other drivers.
> I.e. Append the motherboard ID to the chip name, and also use that to create
> the needed sysfs files. Voila, you don't need "label" sysfs files anymore
> because you can put a section in sensors.conf for each variant of uguru3.
>
> It's not that I'm against the label files per se. But IMHO this suggestion
> is the closest fit to the existing model of operation.
You're speaking as if the motherboard config file database and its
sensors-detect integration are never going to happen. I certainly hope
they will, and this makes your point pretty moot IMHO. Ultimately, we
want a configuration file for every motherboard, and we want it to be
selected automatically based on DMI information. With this in place,
appending the ID to the chip name doesn't buy us anything.
The idea of a sensors.conf.eg file with all chip configurations in it
comes from 1999 or so, we've all seen how broken it is nowadays (and
this has nothing to do with the abituguru3 driver.) Designing drivers
today based on a poor design decision taken 8 years ago doesn't sound
particularly smart.
So, no, I don't think that appending the ID to the device name makes
much sense, sorry.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
next prev parent reply other threads:[~2007-06-18 18:31 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-08 14:30 [lm-sensors] Proposal Hans-Jürgen Koch
2007-04-08 17:36 ` Hans de Goede
2007-04-08 18:31 ` Hans-Jürgen Koch
2007-04-08 18:56 ` Hans de Goede
2007-04-08 19:18 ` Hans-Jürgen Koch
2007-04-09 11:23 ` Jean Delvare
2007-04-09 11:27 ` Jean Delvare
2007-04-09 12:24 ` Jean Delvare
2007-04-09 12:26 ` Hans de Goede
2007-04-09 12:34 ` Hans de Goede
2007-04-09 12:50 ` Hans de Goede
2007-04-11 11:35 ` Jean Delvare
2007-04-11 11:49 ` Jean Delvare
2007-04-11 11:56 ` Jean Delvare
2007-04-11 13:49 ` Hans de Goede
2007-06-16 15:14 ` Mark M. Hoffman
2007-06-16 15:21 ` Mark M. Hoffman
2007-06-16 15:42 ` Mark M. Hoffman
2007-06-16 19:35 ` Hans de Goede
2007-06-16 19:40 ` Hans de Goede
2007-06-16 19:50 ` Hans de Goede
2007-06-16 19:52 ` Mark M. Hoffman
2007-06-18 18:31 ` Jean Delvare [this message]
2007-06-18 19:58 ` Hans de Goede
2007-06-19 7:59 ` Jean Delvare
2007-06-19 8:15 ` Jean Delvare
2007-06-19 8:31 ` Hans de Goede
2007-06-19 12:27 ` Mark M. Hoffman
2007-06-24 11:43 ` Jean Delvare
2007-06-24 12:11 ` 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=20070618203133.4f14831c@hyperion.delvare \
--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.