lkml.org 
[lkml]   [2003]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject2.6 - sysfs sensor nameing inconsistency
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:46    [W:0.057 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site