[lm-sensors] generic chip support in libsensors

[lm-sensors] generic chip support in libsensors

[Hans de Goede]

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

[lm-sensors] generic chip support in libsensors

[Mark M. Hoffman]

Hi Hans, Rudolf:

* Hans de Goede <j.w.r.degoede at hhs.nl> [2006-07-26 17:11:30 +0200]:
> >> 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.

> Rudolf Marek wrote:
> > Yes this is in long term plan.

In fact, Jean Delvare & I discussed just how we would like to do this
at OLS.  It is long overdue.

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

That sounds great.  But, generic chip/feature discovery was not the first
thing on the plan.  It turns out that libsysfs is getting yanked from a
lot of distros and so that part should be reworked first.  Are you
interested in taking that on?  Apparently, libsysfs was recently written
*out* of udev... we should see what they're doing instead.

I will let Jean reproduce the rest of the plan here from his notes.

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

This was never really a question in my mind.  I recognize that we've been
asked for a LGPL library in the past... too bad for them.  I'm not going to
take on the job of rewriting *all* of libsensors just to accomodate a license
change.  I think that I've brought Jean around to the same thinking.

> 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 will back you.  The fear of what a huge task it would be to rewrite
it has prevented us from simply maintaining it.  I've been saying that
we should evolve it instead of rewriting it for some time now.  I've
tried to improve the code every time I touch it... although I guess the
libsysfs stuff I did turns out to be short-lived.

Thanks & regards,

-- 
Mark M. Hoffman
mhoffman at lightlink.com

[lm-sensors] generic chip support in libsensors

[Hans de Goede]

Mark M. Hoffman wrote:
> Hi Hans, Rudolf:
> 
> * Hans de Goede <j.w.r.degoede at hhs.nl> [2006-07-26 17:11:30 +0200]:
>>>> 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.
> 
>> Rudolf Marek wrote:
>>> Yes this is in long term plan.
> 
> In fact, Jean Delvare & I discussed just how we would like to do this
> at OLS.  It is long overdue.
> 
>> 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).
> 
> That sounds great.  But, generic chip/feature discovery was not the first
> thing on the plan.  It turns out that libsysfs is getting yanked from a
> lot of distros and so that part should be reworked first.  Are you
> interested in taking that on?  Apparently, libsysfs was recently written
> *out* of udev... we should see what they're doing instead.
> 
> I will let Jean reproduce the rest of the plan here from his notes.
> 
>>>> 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.
> 
> This was never really a question in my mind.  I recognize that we've been
> asked for a LGPL library in the past... too bad for them.  I'm not going to
> take on the job of rewriting *all* of libsensors just to accomodate a license
> change.  I think that I've brought Jean around to the same thinking.
> 
>> 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 will back you.  The fear of what a huge task it would be to rewrite
> it has prevented us from simply maintaining it.  I've been saying that
> we should evolve it instead of rewriting it for some time now.  I've
> tried to improve the code every time I touch it... although I guess the
> libsysfs stuff I did turns out to be short-lived.
> 

Okay,

I've finally had some positive feedback from my uguru2 driver testers,
so I'll need to write userspace support for the uguru2 one of these
days. I would prefer to sole this by writing generic 2.6 only chip
support as described above. Before I start doing this, I however would
first like to know wether to use libsysfs for this or not.

As a Fedora developer I've asked what Fedora is planning on doing with
libsysfs now udev no longer needs it. The answer was that since some
other apps and libs (directfb, lm_sensors) use it it will be kept in
Fedora and be maintained there. So we could keep just using OTOH Fedora
also said they would drop it if no one was any longer using it, so it
would not be good to be the last remaining user of libsysfs.

So which way will it be? As soon as this is decided upon I can start
working on generic 2.6 chip support (as time permits).

Regards,

Hans

[lm-sensors] generic chip support in libsensors

[Rudolf Marek]

Hi all,

Maybe we will need a special mailing list for the userspace stuff?

Comments?

Regards
Rudolf

[lm-sensors] generic chip support in libsensors

[Jean Delvare]

Hi Rudolf,

> Maybe we will need a special mailing list for the userspace stuff?
> 
> Comments?

I can't see no need for this. What would be the benefit? The list of
subscribers is likely to be the very same for both lists.

-- 
Jean Delvare

[lm-sensors] generic chip support in libsensors

[Jean Delvare]

Hi Hans, Mark,

Sorry for the late answer, I'm only finishing catching up with e-mail
from my vacation.

> > In fact, Jean Delvare & I discussed just how we would like to do this
> > at OLS.  It is long overdue.

Indeed Mark & I discussed that at the same time you posted to the
list :) I guess it just became obvious to several of us that we could
get a chip-independent library for a relatively low cost. At least lower
than a library rewrite.

> > I will let Jean reproduce the rest of the plan here from his notes.

Here we go. I scanned the sketch I drew at the restaurant with Mark, it
is attached.

The core idea is that in kernel 2.4, the kernel drivers provided the
sensor data, but not enough details about the chip "structure" (number
and type of inputs and features). For this reason the structure info was
put in libsensors. In kernel 2.6, the drivers provide both the
structure and the data, so the structure is redundant between the
drivers and libsensors. For now we try hard to keep both in sync, and
that sucks.

The long term solution is to kill all structure information from
libsensors, which will make it MUCH smaller and reduce the maintenance
work to basically nothing. When we do that we say bye-bye to 2.4
support.

But for now we can start by adding this generic support in the library.

Step 0: add individual alarm and beep files to all 2.6 drivers
Not shown on my sketch because I remembered it the day after. This is
the last step to a truly standard sysfs interface to hwmon chips.

Step 1: let libsensors scan /sysfs to discover the chip features
From there we can generate a structure like the ones hard-coded in
lib/chips.c.

With this alone we should be able to use "sensors -u" on any 2.6
driver. Not user friendly though.

Step 2: add sensor type information to the structure
For now the library is type-agnostic. This worked as long as we had
dedicated printing routines for every chip in "sensors", but the goal
of a chip-independent library is to have completely generic user-space
tools as well. We could let each user-space tool guess the sensor type
from the symbol name, but this would incur redundancy across tools. So
better have libsensors generate this information, and add a function to
the library interface for user-space tools to query for data type.

I'm waiting to see an implementation of this to actually decide if it's
the right thing to do.

Step 3: add generic printing routines to sensors
We want a function to print voltages, one for temperatures, one for fan
speed, and a few others. If libsensors provides the type for every
symbol, we can easily branch to the correct printing routine for every
set of symbols. We have some functions like this already, the idea is
to make them even more generic. For example temperature sensors can
come with many different type of limits (low, high, critical,
hysteresis) and depending on the ones available for a given chip we
need to display everything in the right order with proper formatting.

At this point we should be able to have something like "sensors -u" but
with per-sensor-type formatting so much nicer.

Step 4: new sensors.conf.eg
We need to use the standard symbol names in sensors.conf.eg. So far we
used the old symbol names (from 2.4) and libsensors was converting to
the new ones for 2.6 drivers. These old symbol names make no sense if
the driver interface is probed at runtime.

Step 5: take care of the 2.4 part of things
What to do here is not completely clear yet... Mark suggested killing
everything right away, but I think it's a bit early at this point. I'd
rather tweak the library as needed to allow the new "sensors -u" (which
should become the default) to work even with 2.4, so we can kill all
chip specific code in "sensors" to start with. And kill lib/chips.[ch]
only later.

Most of these steps are in fact independent and could be done in a
different order or even by different persons, however each change by
itself isn't really useful so we'll need to synchronize the efforts.

> > > There are still questions if to rewrite the libsensors and allow LGPL or
> > > change libsensors to what you propose.
> > 
> > This was never really a question in my mind.  I recognize that we've been
> > asked for a LGPL library in the past... too bad for them.  I'm not going to
> > take on the job of rewriting *all* of libsensors just to accomodate a license
> > change.  I think that I've brought Jean around to the same thinking.

Yep, I second that. A GPL library which works is magnitudes more useful
than an hypothetical LGPL library which we may not have the time to
write, ever.

If anyone is worried enough, that person gets to write a LGPL library,
not us.

> I've finally had some positive feedback from my uguru2 driver testers,
> so I'll need to write userspace support for the uguru2 one of these
> days. I would prefer to sole this by writing generic 2.6 only chip
> support as described above. Before I start doing this, I however would
> first like to know wether to use libsysfs for this or not.

That generic code whouls be easier to write than I first thought, but it
is still far from being trivial and will take some time. If you want to
work on it, this is welcome, but adding specific uguru2 code for now
may make sense as well. It can always be removed later.

> As a Fedora developer I've asked what Fedora is planning on doing with
> libsysfs now udev no longer needs it. The answer was that since some
> other apps and libs (directfb, lm_sensors) use it it will be kept in
> Fedora and be maintained there. So we could keep just using OTOH Fedora
> also said they would drop it if no one was any longer using it, so it
> would not be good to be the last remaining user of libsysfs.

There are still lots of package using it. There was a rumor at Suse
that it would be dropped soon, but in fact the libsysfs package is being
upgraded from 1.3 to 2.1 right now. The rumor also said that libsysfs
was no more supported by whoever wrote it, but 2.1 is just out so this
doesn't appear to be true either.

We'd better not wait for the world to settle on the libsysfs case to
work on libsensors. It doesn't matter much if we keep using libsysfs or
not, as long as the job is done. Whoever works on this if free to keep
or drop libsysfs, I don't really care.

If we keep using libsysfs and we end up being the only package doing
so, the distributions who want to get rid of libsysfs get to provide a
patch for libsensors.

> So which way will it be? As soon as this is decided upon I can start
> working on generic 2.6 chip support (as time permits).

Either way is fine with me.

I'll be working on step 0 of my plan for now (individual alarm files),
as soon as we are done with the __must_check fixes, as both set of fixes
confict badly with each other.

-- 
Jean Delvare
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OLS2006_WorldDominationPlan.png
Type: image/png
Size: 75658 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060822/423cc575/attachment-0001.png 

[lm-sensors] generic chip support in libsensors

[Hans de Goede]

Hi all,

Long story :)

I've just started in a new function, where I get to make up projects for
small student groups todo in their final year of their Computer Science
bachelor study. I'm going to define step 2 and 3 as a project for this I
think. I know my Google SOC project hasn't been exactly a success, but
work is still progressing on that. I'm expecting Ivan to post an update
to you all soon.

Let me know if their is anything I should know before I put a bunch of
students to work on this (3 students 12 hours / week for circa 15 weeks).

Regards,

Hans


Jean Delvare wrote:
> Hi Hans, Mark,
> 
> Sorry for the late answer, I'm only finishing catching up with e-mail
> from my vacation.
> 
>>> In fact, Jean Delvare & I discussed just how we would like to do this
>>> at OLS.  It is long overdue.
> 
> Indeed Mark & I discussed that at the same time you posted to the
> list :) I guess it just became obvious to several of us that we could
> get a chip-independent library for a relatively low cost. At least lower
> than a library rewrite.
> 
>>> I will let Jean reproduce the rest of the plan here from his notes.
> 
> Here we go. I scanned the sketch I drew at the restaurant with Mark, it
> is attached.
> 
> The core idea is that in kernel 2.4, the kernel drivers provided the
> sensor data, but not enough details about the chip "structure" (number
> and type of inputs and features). For this reason the structure info was
> put in libsensors. In kernel 2.6, the drivers provide both the
> structure and the data, so the structure is redundant between the
> drivers and libsensors. For now we try hard to keep both in sync, and
> that sucks.
> 
> The long term solution is to kill all structure information from
> libsensors, which will make it MUCH smaller and reduce the maintenance
> work to basically nothing. When we do that we say bye-bye to 2.4
> support.
> 
> But for now we can start by adding this generic support in the library.
> 
> Step 0: add individual alarm and beep files to all 2.6 drivers
> Not shown on my sketch because I remembered it the day after. This is
> the last step to a truly standard sysfs interface to hwmon chips.
> 
> Step 1: let libsensors scan /sysfs to discover the chip features
> From there we can generate a structure like the ones hard-coded in
> lib/chips.c.
> 
> With this alone we should be able to use "sensors -u" on any 2.6
> driver. Not user friendly though.
> 
> Step 2: add sensor type information to the structure
> For now the library is type-agnostic. This worked as long as we had
> dedicated printing routines for every chip in "sensors", but the goal
> of a chip-independent library is to have completely generic user-space
> tools as well. We could let each user-space tool guess the sensor type
> from the symbol name, but this would incur redundancy across tools. So
> better have libsensors generate this information, and add a function to
> the library interface for user-space tools to query for data type.
> 
> I'm waiting to see an implementation of this to actually decide if it's
> the right thing to do.
> 
> Step 3: add generic printing routines to sensors
> We want a function to print voltages, one for temperatures, one for fan
> speed, and a few others. If libsensors provides the type for every
> symbol, we can easily branch to the correct printing routine for every
> set of symbols. We have some functions like this already, the idea is
> to make them even more generic. For example temperature sensors can
> come with many different type of limits (low, high, critical,
> hysteresis) and depending on the ones available for a given chip we
> need to display everything in the right order with proper formatting.
> 
> At this point we should be able to have something like "sensors -u" but
> with per-sensor-type formatting so much nicer.
> 
> Step 4: new sensors.conf.eg
> We need to use the standard symbol names in sensors.conf.eg. So far we
> used the old symbol names (from 2.4) and libsensors was converting to
> the new ones for 2.6 drivers. These old symbol names make no sense if
> the driver interface is probed at runtime.
> 
> Step 5: take care of the 2.4 part of things
> What to do here is not completely clear yet... Mark suggested killing
> everything right away, but I think it's a bit early at this point. I'd
> rather tweak the library as needed to allow the new "sensors -u" (which
> should become the default) to work even with 2.4, so we can kill all
> chip specific code in "sensors" to start with. And kill lib/chips.[ch]
> only later.
> 
> Most of these steps are in fact independent and could be done in a
> different order or even by different persons, however each change by
> itself isn't really useful so we'll need to synchronize the efforts.
> 
>>>> There are still questions if to rewrite the libsensors and allow LGPL or
>>>> change libsensors to what you propose.
>>> This was never really a question in my mind.  I recognize that we've been
>>> asked for a LGPL library in the past... too bad for them.  I'm not going to
>>> take on the job of rewriting *all* of libsensors just to accomodate a license
>>> change.  I think that I've brought Jean around to the same thinking.
> 
> Yep, I second that. A GPL library which works is magnitudes more useful
> than an hypothetical LGPL library which we may not have the time to
> write, ever.
> 
> If anyone is worried enough, that person gets to write a LGPL library,
> not us.
> 
>> I've finally had some positive feedback from my uguru2 driver testers,
>> so I'll need to write userspace support for the uguru2 one of these
>> days. I would prefer to sole this by writing generic 2.6 only chip
>> support as described above. Before I start doing this, I however would
>> first like to know wether to use libsysfs for this or not.
> 
> That generic code whouls be easier to write than I first thought, but it
> is still far from being trivial and will take some time. If you want to
> work on it, this is welcome, but adding specific uguru2 code for now
> may make sense as well. It can always be removed later.
> 
>> As a Fedora developer I've asked what Fedora is planning on doing with
>> libsysfs now udev no longer needs it. The answer was that since some
>> other apps and libs (directfb, lm_sensors) use it it will be kept in
>> Fedora and be maintained there. So we could keep just using OTOH Fedora
>> also said they would drop it if no one was any longer using it, so it
>> would not be good to be the last remaining user of libsysfs.
> 
> There are still lots of package using it. There was a rumor at Suse
> that it would be dropped soon, but in fact the libsysfs package is being
> upgraded from 1.3 to 2.1 right now. The rumor also said that libsysfs
> was no more supported by whoever wrote it, but 2.1 is just out so this
> doesn't appear to be true either.
> 
> We'd better not wait for the world to settle on the libsysfs case to
> work on libsensors. It doesn't matter much if we keep using libsysfs or
> not, as long as the job is done. Whoever works on this if free to keep
> or drop libsysfs, I don't really care.
> 
> If we keep using libsysfs and we end up being the only package doing
> so, the distributions who want to get rid of libsysfs get to provide a
> patch for libsensors.
> 
>> So which way will it be? As soon as this is decided upon I can start
>> working on generic 2.6 chip support (as time permits).
> 
> Either way is fine with me.
> 
> I'll be working on step 0 of my plan for now (individual alarm files),
> as soon as we are done with the __must_check fixes, as both set of fixes
> confict badly with each other.
> 
> 
> 
> ------------------------------------------------------------------------
> 

[lm-sensors] generic chip support in libsensors

[Jean Delvare]

Hi Hans,

> Long story :)
> 
> I've just started in a new function, where I get to make up projects for
> small student groups todo in their final year of their Computer Science
> bachelor study. I'm going to define step 2 and 3 as a project for this I
> think. I know my Google SOC project hasn't been exactly a success, but
> work is still progressing on that. I'm expecting Ivan to post an update
> to you all soon.

I hope soo, too.

> Let me know if their is anything I should know before I put a bunch of
> students to work on this (3 students 12 hours / week for circa 15 weeks).

First of all, please make sure everything is clear with regards to code
ownership and licensing issues. Any code contributed to our project
must be GPL.

I would suggest that your students familiarize themselves with the
lm_sensors project before coding on it. They better be users of the
project first, find out how to get it to work on their specific
hardware, including the configuration file. Then they should subscribe
to this list and see the kind of issues we have. Only with this
background they will understand why we want to change the libsensors
concept fundamentally. And only if they understand why the change is
needed, they have a chance to get it right.

More manpower is always welcome :) If the students could even join the
project and stay for longer, that would be even better. There are so
many fixes, improvements, reviews etc. in my queue...

-- 
Jean Delvare

[lm-sensors] generic chip support in libsensors

[Bob Schlärmann]

Hello all,

Hans de Goede recently mentioned that he would put up a student project
to let them work on some of the steps needed for generic chip support.
I'm a student of Hans and together with 2 others we have taken on this
project. All of us have experience in programming with Linux and
we think we understand the problems libsensors is currently facing with
adding support for new chipsets. We also realise that any code we
release will be subject to the gpl.

We would first like to focus on steps 1 (use sysfs to discover a chip's
features) and 3 (generic print routines in 'sensors'). The following are
summaries of the objectives as we formulated them:

for step 1: modify the library so that it wil not be necessery anymore
to add seperate support code into the library for newly supported chips.

step 3: modify the sensors tool print routines to add support for types
of sensors instead of the current support for types of chips.

Our plan was to first begin with step 1 and release code for it as soon
as possible, as to get an idea of how the cycle of releasing and
testing goes. Later on we will begin with step 3.

One question we have is whether it is a good idea to work on step 3
without dealing with step 2 (add sensor type info to structure) first.
Because once step 2 is implemented, step 3 seems easier to accomplish.

--
Bob Schl?rmann, project leader

[lm-sensors] generic chip support in libsensors

[Mark M. Hoffman]

Hi Bob:

I apologize for the very late reply.

* Bob Schl?rmann <bob2 at dsv.nl> [2006-09-09 17:13:36 +0200]:
> Hans de Goede recently mentioned that he would put up a student project
> to let them work on some of the steps needed for generic chip support.
> I'm a student of Hans and together with 2 others we have taken on this
> project. All of us have experience in programming with Linux and
> we think we understand the problems libsensors is currently facing with
> adding support for new chipsets. We also realise that any code we
> release will be subject to the gpl.
> 
> We would first like to focus on steps 1 (use sysfs to discover a chip's
> features) and 3 (generic print routines in 'sensors'). The following are
> summaries of the objectives as we formulated them:
> 
> for step 1: modify the library so that it wil not be necessery anymore
> to add seperate support code into the library for newly supported chips.
> 
> step 3: modify the sensors tool print routines to add support for types
> of sensors instead of the current support for types of chips.
> 
> Our plan was to first begin with step 1 and release code for it as soon
> as possible, as to get an idea of how the cycle of releasing and
> testing goes. Later on we will begin with step 3.

Sounds good to me.  If you want, we can grant you SVN access provided that you
keep your work on a separate branch.

> One question we have is whether it is a good idea to work on step 3
> without dealing with step 2 (add sensor type info to structure) first.
> Because once step 2 is implemented, step 3 seems easier to accomplish.

I spoke to Jean Delvare about this on IRC[1].  We agreed that completing step 3
before step 2 has in fact some advantages of its own.  In particular, step 2
involves adding some functions to the libsensors API - it may be helpful to see
what the "users" need before finalizing that.  

Anyway, if that's the order you prefer, that's OK.

[1] #linux-sensors on irc.freenode.net

Regards,

-- 
Mark M. Hoffman
mhoffman at lightlink.com

[lm-sensors] generic chip support in libsensors

[Rudolf Marek]

Hi Bob,

Any news on this?

Thanks,
Rudolf

[lm-sensors] generic chip support in libsensors

[Bob Schlärmann]

Hello,

We are currently almost done with modifying the library so that it
detects the chip's features from the sysfs entries, it now needs
some testing. One problem we had was finding a way to add the new
sensors_chip_features entry to the global list of known chips. This is
currently handled by making the last places of the global array empty
placeholders.

For step 2/3 (modify the sensors tool so the per chip print routines are
replaced by generic ones) we had some ideas. 

The first idea was to create a sort of object oriented approach by using
structs and function pointers, kind of how Gtk works. In the
OO-model a Sensor class/struct would be the root class and cpu,
voltage, etc. sensors would be implemented as subclasses. This has the
advantage (in our opinion) of a clear API and makes adding new sensor
types easier.

A simpler approach would be to just create a function that returns the
correct sensor type given a sensor_chip_feature struct. The sensors app
can then be restructured around this.

We have currently chosen to first implement the the last approach,
because this seems more 'incremental', and when there is enough time
left (there probably will be) implement the oo-model as an extra layer.

A patch will be available soon, to show our current progress and
hopefully to get some feedback whether we took the right path with step
1,

--
Bob

On Mon, 16 Oct 2006 22:43:26 +0200
Rudolf Marek <r.marek at assembler.cz> wrote:

> Hi Bob,
> 
> Any news on this?
> 
> Thanks,
> Rudolf
> 
> _______________________________________________
> lm-sensors mailing list
> lm-sensors at lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
> 
> !DSPAM:4533ef46130231804284693!
> 

[lm-sensors] generic chip support in libsensors

[Jean Delvare]

Hi Bob,

Sorry for being so quiet, that's because I am very busy, not because
I'm not interested. I _am_ very interested by your work.

I am worried about how you are currently keeping your changes? At some
point we'll have to merge your changes upstream, and we are not going
to take one big patch with all changes. We need incremental changes so
that we can review and test them properly.

It might make sense to open a branch for you in our Subversion
repository so that you can do these incremental commits right now, and
we can comment and review and test as you progress.

On Tue, 17 Oct 2006 00:02:57 +0200, Bob Schl?rmann wrote:
> We are currently almost done with modifying the library so that it
> detects the chip's features from the sysfs entries, it now needs
> some testing. One problem we had was finding a way to add the new
> sensors_chip_features entry to the global list of known chips. This is
> currently handled by making the last places of the global array empty
> placeholders.

This means you put an arbitrary limit to the number of entries which
can be created dynamically. This is certainly OK if this limit is large
enough, as a first approximation. But dynamic entries are supposed to
become the one and only way in the future, so it'd be better if we
could handle them cleanly. This might come naturally when we drop
support for static entries anyway.

> For step 2/3 (modify the sensors tool so the per chip print routines are
> replaced by generic ones) we had some ideas. 
> 
> The first idea was to create a sort of object oriented approach by using
> structs and function pointers, kind of how Gtk works. In the
> OO-model a Sensor class/struct would be the root class and cpu,
> voltage, etc. sensors would be implemented as subclasses. This has the
> advantage (in our opinion) of a clear API and makes adding new sensor
> types easier.
> 
> A simpler approach would be to just create a function that returns the
> correct sensor type given a sensor_chip_feature struct. The sensors app
> can then be restructured around this.

This was my original intent, yes. Just add this function to the
libsensors API and you're done.

> We have currently chosen to first implement the the last approach,
> because this seems more 'incremental', and when there is enough time
> left (there probably will be) implement the oo-model as an extra layer.

I prefer the last approach too. No need to make things more complex
than is required. "sensors" is written in C, not an OO language.
And we haven't been adding a new sensor type in the past 6 years, I
pretty much doubt we'll have to add any in a near future, so no need to
optimize for this unlikely event.

> A patch will be available soon, to show our current progress and
> hopefully to get some feedback whether we took the right path with step
> 1,

Great, looking forward :)

-- 
Jean Delvare