[lm-sensors] Proposal /sys/bus/class/hwmon/hwmon#/device/foo#_label

[Mark M. Hoffman]

Hi Hans:

* Hans de Goede <j.w.r.degoede at hhs.nl> [2007-06-16 21:50:20 +0200]:
> Mark M. Hoffman wrote:
> >Hi everyone:
> >
> >Finally, back to the thread that resulted in change of maintainers, but not
> >yet any merged code. ;)
> >
> >* Hans de Goede <j.w.r.degoede at hhs.nl> [2007-04-11 15:49:08 +0200]:
> >>Jean Delvare wrote:
> >>>Hans,
> >>>
> >>>On Mon, 09 Apr 2007 14:26:06 +0200, Hans de Goede wrote:
> >>>>Jean Delvare wrote:
> >>>>>This is absolutely not different from all other hardware monitoring
> >>>>>drivers. And all other drivers handle it in user-space, because that's
> >>>>>the right design. I see no valid reason why it would be different for
> >>>>>your abituguru3 driver. All you need is one configuration file per
> >>>>>motherboard.
> >>>>Actually it is _very_ different. The uguru is not a chip, its more a 
> >>>>piece of software (looking from the driver POV) then a chip, thus 
> >>>>sensors which aren't there really aren't there, they are not just 
> >>>>unconnected pins, they _really_ aren't there.
> >
> >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.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.
> >
> 
> I could do that, actually making the ID available in some way to userspace 
> is a good idea, however I'm still in favor of the fooX_label approach 
> because:
> 
> 1) The driver will need the table it currently has no matter what, to 
> determine
>    which inputs the model / this specific member of the family has, and at
>    which addresses these inputs reside and what type they have.
> 
>    Since the table is already there, I might as well at the labels there and
>    have all info in a single place == less maintainance / no sync problems

I anticipated that argument, and I can't disagree.  I only wanted to propose
something that was perhaps less controversial.

> 2) With dyn chip support in place (soon hopefully) a newer kernel with 
> support
>    for new motherboards added to the table, will just work without requiring
>    userspace updates. When the labels are in sensors.conf userspace will 
>    need
>    updating too, and if sensors.conf has been edited, it will require manual
>    intervention / editing  even.
> 
>    More in general if other drivers, for example CPU / chipset internal
>    sensor temp drivers get added, they can have foo#_label sysfs entries 
>    too,
>    and the new dyn chip support libsensors will do the right thing.
> 
>    Atleast Fedora, and probably other distro's update the kernel way more 
>    often
>    then userspace tools.
> 
> >>So is this one, its reading the configuration register which tells the 
> >>driver which model/stepping we are running on.
> >
> >Yep, this leads directly to my suggestion above.  Guys, is that acceptable?
> >(/me is out, but leaving the rest uncut since it's such an old thread)
> >
> 
> If the above solution is what it takes to gets the driver integrated, then 
> maybe I can agree, but I see big pain (mainly for me) in having to maintain 
> the needed table partly in the driver and partly in sensors.conf, since the 
> driver will need a table anyways, why not put all the info in one place?
> 
> ---
> 
> I've feeling we're arguing about 2 different things at once here, so here 
> is a try to split them:
> 
> 1) do we want foo#_label sysfs entries for devices were we can give a 
> sensible
>    label to userspace, like cpu temp drivers
> 2) if we agree that we want / will allow 1), is it ok for the uguru3 driver 
> to
>    generate foo#_label sysfs entries using the contents of an uguru3 
>    register
>    which addresses a lookup table with the actual info.

Without allowing #2, I would say #1 is pointless...

But I've heard enough: IMHO the answers are yes and yes.  Would you please
respin your patch against v2.6.22-rc4 and I'll look at it as soon as I can.

Regards,

-- 
Mark M. Hoffman
mhoffman at lightlink.com