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. > Nope, the motherboard ID used by the chip is a 16 bit unsigned int, not some kinda string like dmidecode gives. >> 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. > Actually it is _very_ different. The uguru is not a chip, its more a piece of software (looking from the driver POV) then a chip, thus sensors which aren't there really aren't there, they are not just unconnected pins, they _really_ aren't there. And afaik some drivers have magic and or module options to not generate generate certain sysfs entries in certain cases, this is no different. Also this is they way how Abit handles this. The windows software comes with an ini-files, each named with the hex value of the ID, and that is used to determine how to talk to the uguru (which addresses to use) and what to ask. Last but not least, this way (with libsensors-support and/or dyn chip support), the experience is truely plug and play, isn't that what we want in the end? The same argument could be made for PCI ID tables in the kernel for hardware not essential to booting (or through ramdisk, even for boot essential hardware) why have the PCI-id's in the kernel? Why not have them in userspace and always use the new_id sysfs files? Again the same argument could be made for blacklists / whitelists for many things in the kernel. There always is a trade-off, between putting this info in the kernel or in userspace. You yourself agreed, that given the limited amount of motherboards featuring the uguru, it might even be an idea to add an export a dmi-info-table with the supported motherboards to the driver, how is this different? Regards, Hans
