> Some temperature sensors have two types of alarms. An over-limit > (max_alarm) alarm and a sensors failed alarm. > > We could do this a couple of different ways: > > 1. Name the alarm file for a sensor: temp1_alarm and have it take one > of several values: "" (null string), "ALARM", "FAIL" > > 2. Come up with another name for the other alarm: temp1_input_failed? > temp1_fail_alarm? > > 3. Some other idea I haven't thought of? Thanks for pointing that out. We really need to have a global view of all drivers if we want to make it correct on the first try, and there are at least two dozen chip drivers I never took a look at, so I need assistance. My initial idea was 2. I wasn't thingking of failed yet (although I have to admit that at least one driver I have been working on does have it - lm83 or lm90, I can't remember). I was thinking of beeps, for chips that have a beeps register matching alarms. This means that if we consider 1, we sometimes would need more than one string, because for example alarm and beep typically occur at the same time. Although this is easy to read for a human, it is likely to require some additional parsing code in the library. If we now consider 2, this means that the number of files will increase significantly. For example, we can easily imagine a single temperature channel needing the following files: temp1_input temp1_min temp1_max temp1_max_hyst temp1_over temp1_over_hyst temp1_alarm temp1_fail temp1_beep Even more if you consider that there may be different alarm bits for different limits. For example, it would make sense to have something like: temp1_input temp1_fail temp1_max temp1_max_hyst temp1_max_alarm temp1_max_beep temp1_over temp1_over_hyst temp1_over_alarm temp1_over_beep We could suspect that one single beep file would be sufficent, since we already can check the individual alarm files to see which limit has been crossed. But I think that some chips allow individual beep disabling, so if two alarms have triggered, it wouldn't be possible to determine because of which the system is beeping. The question is to know if we really care, or not. Now that we speak about it, such systems would need additional files: temp1_max_beep_enable temp1_over_beep_enable Think of complete monitoring chips such as the w83781d and family, this could lead to many, many files. The list above shows that we can reasonably expect 10 files per item, and such chips can have, say, 13 items, which leads to the very approximate value of 130 files (although fans and voltages probably will have less files in average than temperatures, so let's say 100 files total). Greg, is it correct to have such a high number of sysfs files for a driver? If not, I have a solution 3. We could define an arbitrary bit order for indiviual alarm files, much in the idea of current alarm files, but where the order of the bits wouldn't be chip-dependant. Example: 1<<0 = alarm 1<<1 = beep 1<<2 = fail This leaves some root for future extensions, while still limiting the number of files and being fast to "parse" (i.e. no parsing required). One drawback over 1 is that it is less easily readable by a human, also a simple rule apply (0 = OK, else there's at least one thing wrong). One drawback over 2 is that someone (or something) parsing the sysfs directory doesn't know wether a given bit is supported by the chip (unless that bit is set at the moment). I see the sysfs files as a very interesting way to actually describe what a chip can do or not. This begins with the items themselves, then the limits/divisors/etc that apply to them, and it would probably be great if this could be extended to just anything, including alarm bits. I think we really need to go on thinking about it all :) Thanks. -- Jean Delvare http://www.ensicaen.ismra.fr/~delvare/
