Ed Lucas wrote: > > Can anyone point me towards a description of the "dynamic chips support" > for libsensors that Jean mentioned. (Sorry, my googling failed on this). > Currently libsensors has a table, with for each supported chip a table in this table (thus a tabel of tables) the per chip table lists all the features of the chip and how they are related to each other (IOW if they share computation rules, etc). The big downside of this is that every time a new chip gets supported (like the uguru) then this table and thus libsensors need to be updated. Since some distro's tend to update the kernel more often then userspace libs, this means that people can have a kernel supported chip which is not working because libsensors doesn't understand it. With the new sysfs interface in kernel 2.6, all the needed information can actually be "queried" from the sysfs interface, thus removing the need for this table, this is what we call "dynamic chips support", AFAIK the impact on the dmi based autoconfig stuff we're working on is minimal. The only relevant change is the libsensors names of sensors. For most chips sensors currently are named things like in0, in1, etc. So one can write: label in1 "foo bar" However some chips (GRRR) have names like VDD5V, so one should write: label VDD5V "foo bar" With dynamic chip supports, things become consistent and for example volt sensors will always be called in0 in1, etc. This actually is an improvement, but does mean that old sensors.conf's need to be converted. This is very much AFAIK, others please correct me if I'm wrong here. As discussed earlier the plan is to only target the new 3.x version of libsensors with the dmi based stuff, so there is no real problem, we just need to make sure any sensors.conf files in the "database" use the new names. > For motherboard specific sensors.conf files, would it make sense to use > the same fan labels that are used in the manual and on the motherboard > itself? (What is the offical naming policy? - grepping sensors.conf > shows a range of names) > For the abituguru files in the wiki I've tried to use the exact same names as in the bios. AFAIK there is no policy for this. Also notice that libsensors 3.x will have a new api funciton, allowing one to query the type of a sensor, so then it will not be needed to prefix labels like you've done to find out the type. Regards, Hans
