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/
This archive was generated by hypermail 2b29 : Tue Jul 15 2003 - 22:00:59 EST