Messages in this thread | | | From | Andrey Borzenkov <> | Subject | 2.6 - sysfs sensor nameing inconsistency | Date | Tue, 15 Jul 2003 22:14:38 +0400 |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |