tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: envsys issues [was Re: envstat wrong: who's at fault?]

On Mon, 26 Jul 2010, der Mouse wrote:

[moved from port-i386]

In passing, would it be appropriate and/or useful to suggest
improvements to [the envsys(4)] API?  When I was writing code, I
found the envsys(4) ioctls to be deficient for my purposes.
[Paul Goyette]
I'd be interested in knowing in which ways you found the current API
lacking.  [...]

Well, some things are underdocumented.  For example, it seems that most
sensors are not in the units specified by envsys_tre_data_t.units, but
rather in 1e-6 of that unit - for example ENVSYS_SWATTHOUR sensors are
not in watthours but in microwatthours - and, as far as I've been able
to find, this factor of 1e6 is not documented anywhere but the source
to envstat(8).  Except for temperature, which is specifically said to
be in microKelvins.  But others are said to be in volts, amps, etc.  To
quote both the envsys(4) and <sys/envsys.h>,

                    union {                         /* all data is given */
                            uint32_t data_us;       /* in microKelvins, */
                            int32_t data_s;         /* rpms, volts, amps, */
                    } cur, min, max, avg;           /* ohms, watts, etc */
                                                    /* see units below */

This is greatly cleaned up in the envsysV2 implementation.

If the "micro" is supposed to apply to all those units, not just
Kelvins, then (a) "rpms" needs to be removed from the list and (b) the
wording needs to be improved.

But the one piece I've found so far that isn't just a lack of
documentation (well, unless there are totally undocumented calls) is
that there's no way to fetch multiple sensors' values without potential
for skew between them..  For example, to quote from the code I've been

In envsysV2, a single call is used to retrieve the whole set of sensors (in a prop dictionary) so you don't need to worry about skew caused by userland sampling. Of course, there is still the possibility of skew caused by the driver's need to fiddle with hardware registers.

| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:       |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at    |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at |
| Kernel Developer |                          | pgoyette at  |

Home | Main Index | Thread Index | Old Index