All of lore.kernel.org
 help / color / mirror / Atom feed
From: j.w.r.degoede@hhs.nl (Hans de Goede)
To: lm-sensors@vger.kernel.org
Subject: [lm-sensors] generic chip support in libsensors
Date: Wed, 26 Jul 2006 15:11:30 +0000	[thread overview]
Message-ID: <44C78622.8060808@hhs.nl> (raw)



Rudolf Marek wrote:
> 
> Hi Hans,
> 
> 
>> I was thinking about doing things differently with regards to userspace.
>> As I already posted to the list I'm working on a driver for the uGuru2.
>> The driver is done (waiting for feedback from testers) but I still need
>> todo userspace. Since the uGuru2 driver is going to be 2.6 only and
>> since 2.6 has a clear API/ABI between userspace and the kernel for hwmon
>> chips I was thinking about adding code to libsensors for generic 2.6
>> support. The idea is to write a piece of code which will come into
>> action only if libsensors doesn't have a chip definition for a found
>> chip and libsensors is running on a  2.6 kernel. This piece of code
>> would then fill a dynamicly allocated structure describing the unknown
>> chip, using the same structure as for known chips.
> 
> Yes this is in long term plan.
> 

I know it has been the long term plan for a while, my suggestion is to
write an intermediate solution for the short term (say within a couple
of weeks) this short term solution would only kick into action for new
chip drivers (like your k8 temp driver) leaving the behaviour unchanged
for chips currently already supported by libsensors (although the 2.6
only ones may be removed after thorough testing making libsensors smaller).

>> Does this sound like a plan With this in place we no longer need to
>> write support for every new 2.6 hwmon driver, actually if this goes in I
>> would like to see explicit support for the uGuru (1) be removed, since
>> this generic code should do just as good of a job.
> 
> Yes.
> 
> There are still questions if to rewrite the libsensors and allow LGPL or
> change libsensors to what you propose.
> 

I know, what I propose is not to wait for a decission but instead add
support for unknown 2.6 driven chips to libsensors, leaving things as is
for already supported chips. This way we no longer need to update
libsensors each time a new 2.6 driver is added. I've been planning to
write a patch for this evolutionary change for a while now. But first I
would like to see some people backing the concept, I don't like writing
code with 0%chance of getting it integrated upstream.

> I'm  leaving now for two weeks so please be patient with further answers
> from me.
> 

I know, this mail is meant for the whole list, not just for you. Have a
good vacation!

Regards,

Hans


             reply	other threads:[~2006-07-26 15:11 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-26 15:11 Hans de Goede [this message]
2006-07-27  1:18 ` [lm-sensors] generic chip support in libsensors Mark M. Hoffman
2006-08-01  8:06 ` Hans de Goede
2006-08-20 10:50 ` Rudolf Marek
2006-08-20 12:26 ` Jean Delvare
2006-08-22 10:01 ` Jean Delvare
2006-08-24 19:32 ` Hans de Goede
2006-08-25  8:31 ` Jean Delvare
2006-09-09 15:13 ` Bob Schlärmann
2006-10-05 13:00 ` Mark M. Hoffman
2006-10-16 20:43 ` Rudolf Marek
2006-10-16 22:02 ` Bob Schlärmann
2006-10-18 15:13 ` 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=44C78622.8060808@hhs.nl \
    --to=j.w.r.degoede@hhs.nl \
    --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.