RFC lmsensors sysfs interface documentation
khali at linux-fr.org
Tue Mar 29 10:26:08 CEST 2005
> Hi All,
> I've started a little documentation project here:
> So far I generated list of sysfs interface names, culled the
> documented ones and produced a second list.
> I don't know if anyone has a cross-reference which driver uses
> what name but I'm thinking of producing one, perhaps a table,
> X = drivers, Y = sysfs names, * marks the spot? This been done?
Sounds good, has not been done yet.
> Worth doing?
Certainly, but only if you find a way to automate this. If not, the
drivers are changed and added as such a fast pace these days that you
would certainly regret the time you spent doing it manually quite
> Comments, suggestions welcome.
I have a lot of them.
First, you would probably make things easier to read and analyze by
collapsing names changing only by their channel number. Where the
documentation says temp[1-4]_input, it really (almost) means
temp[anynumber]_input. The "1" is valuable because some counts start
at 0 (most notably voltage channels and CPUs) and it's better to know
which, but the "4" is totally arbitrary, and is there just because
that was the max number at the time the documentation was written. This
would be better written temp[1-*]_input, or anything similiar which
really expresses the lack of upper limit. This way we could focus on the
masks rather than the exact names.
rt[1-3] is now gone thanks to your patch to w83781d.c.
fan[1-3]_ripple is NOT fan[1-3]_div. As explained in a previous post,
ripples are the number of pulses per revolution. They are a kind of fan
divider, but fundamentally different from fan[1-*]_div which are fan
*clock* dividers. A more "standard" name for fan[1-3]_ripple would
probably be "fan[1-*]_ppr". I think I remember that some 2.4 driver
wdog_* should definitely be changed to watchdog_*, and these should be
documented. That being said, maybe it'd be even better to look at real
watchdog drivers and use the standard interface rather than our own.
revision and die_code are the same thing. Both should be removed IMHO,
revision should not be needed by user-space, and it's cheaper to just
printk it on driver load (if this is of any use at all).
Almost each item on your nondoc list would require specific treatment.
That's quite a lot of work...
I really appreciate that you tackle issues that affect all the drivers at
once, but at some point you might find more fun and interest in going on
with your adm9240 driver port. Once you have a working driver you can
play with, you will most probably have an even better understanding of
the subsystem as a whole, which will help you focus on points you think
Keep up the good work,
More information about the lm-sensors