Jean Delvare wrote: > Hi Hans, > > On Sun, 08 Apr 2007 19:36:47 +0200, Hans de Goede wrote: >> Hans-J?rgen Koch wrote: >>> Am Sonntag 08 April 2007 15:51 schrieb Hans de Goede: >>> >>>> The abituguru3 has a register which contains a motherboard ID. The current >>>> driver uses this ID, to look up info about the motherboard in a somewhat >>>> lenght table in the driver. >>> Can you elaborate your design decision a bit? My first idea would be to have >>> a sysfs file that delivers that motherboard ID and then do the lookup in >>> user space. > > I guess that the motherboard ID can be retrieved in user-space using > dmidecode, can't it? So it might not even be needed to export it. > >> As I don't want the abituguru3 driver to create entries in sysfs for sensors >> which aren't there, and as without the table in the driver I cannot be sure >> wether to create an in / temp / fan device for a given sensor address. Last but >> not least doing things this way allows me to always give a proper reading >> without userspace needing to "guess" any further nescesarry calculations to get >> from the reading to an actual measurement. > > This is absolutely not different from all other hardware monitoring > drivers. And all other drivers handle it in user-space, because that's > the right design. I see no valid reason why it would be different for > your abituguru3 driver. All you need is one configuration file per > motherboard. > Oh and another thing I just came up with, last time I checked, it isn't possible from userspace to change an inX_input to a tempX_input, or are you suggesting that I export all 48 sensors, 3 times, once as in, once as temp and once as fan and them make user space ignore temp1 and fan1, and use in0, as sensor 0/1 actually is an in sensor? Regards, Hans
