2.6 - sysfs sensor nameing inconsistency

[Andrey Borzenkov <arvidjaar@mail.ru>]

In 2.4 all sensor chip got a subdirectory with name derived from type_name - a 
single word describing sensor, like

adm1021.c:              type_name = "max1617";
adm1021.c:              type_name = "max1617a";
adm1021.c:              type_name = "adm1021";
adm1021.c:              type_name = "adm1023";
adm1021.c:              type_name = "thmc10";
adm1021.c:              type_name = "lm84";
adm1021.c:              type_name = "gl523sm";
adm1021.c:              type_name = "mc1066";
...

etc. All user-level configuration (sensors, gkrellm) have been using these 
names to match available sensors and configuration data.

In 2.6 sensors appear under /sysfs, type_name no more used and the only 
identification available is .../name, but it seems to be arbitrary chosen 
like

- single word ("it87") - lm87.c
- "name chip" or "name subclient" - most others (lm78.c, wd83781d.c etc)
- completely arbitrary shiny description - "Generic LM85", "National LM85-B" 
etc in lm85.c

This means, any user program accessing sensors need incompatible changes and 
comfiuration cannot be shared between 2.4 and 2.6 without serious redesign 
and/or some translation layer.

If there are serious reasons to keep current names in "name" - what about 
adding extra type_name property that will hold type_name compatible with 2.4, 
at least for those drivers that are also available there. This would allow 
easily reuse existing sensors configuration.

TIA

-andrey