Proposal to individual alarm/beep sysfs files

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

 



Jean Delvare wrote:

>The original discussion was between per-type files versus per-channel
>files. I think we agreed that individual files were better, allowing a
>much cleaner implementation. Per-type files would require us to reorder
>all bits when the chip has them in a random order (which is most often
>the case, unfortunately). With per-channel files, we just have to
>extract the correct bit, which is easy. We can even use the same
>callback for all alarms, as demonstrated at the end of this post.
>
>Now, some chips offer more than one alarm for a given channel. For
>example the LM90/ADM1032 has a separate alarm for low limit crossed,
>high limit crossed and critical limit crossed. It was suggested that we
>could have non-boolean alarm files, and it makes some sense. However,
>on second though, it means that we would have to define a standard bit
>order inside such alarm files, and we'll have to build the contents
>from the registers. This won't be easier than having per-type files,
>which we said we did not want to do.
>
>So my new suggestion is to have per-limit alarm files for chips which
>implement things that way. This makes every alarm file a boolean. The
>only drawback I can think of is that we'll end up with many more sysfs
>files defined in each driver. However, the size increase seems to be
>acceptable, thanks to the dynamic sysfs callbacks and the array of
>attributes which we can use now.
>
>Fault conditions and beep masks can be handled exactly the same way.
>  
>

What about using strings in the alarm files instead of booleans?  Then 
you could report the *name* of the limit or condition causing the alarm 
(or alarms) or an empty string if there is no alarm?

When you look at the code in libsensors, it seems that alarms are almost 
always converted into text strings.  Why not move that code into the 
driver itself and then user-space tools would just print the contents of 
the ALARM file rather than having to parse the alarm file name to 
determine what limit or condition is causing the alarm or fault.

:v)






[Index of Archives]     [Linux Kernel]     [Linux Hardware Monitoring]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux