Bill Nottingham wrote:
Hans de Goede (j.w.r.degoede(a)hhs.nl) said:
> Because sensors are not plug and play, unfortunatly they are not plug
> and play at all. They are either on an i2c bus which doesn't do plug and
> play or on the isa bus without isapnp support, so there is no way to
> automagicly find which sensor chips there are, even if you manage to
> find out which sensor chips there are, there is no way to find out
> whioch voltage / temp / fan is connected to which input, and if they are
> divided (using resistors) before being connected.
>
> Luckily they are however usually soldered onto the motherboard, so which
> chips there are and how they are hooked up is fixed for a given
> motherboard. Hence the idea to use a database with this info per (known)
> motherboard and a tool which uses this database to generate the correct
> configuration.
I'm somewhat talking out of my ass here, but:
Then, have platform devices that export DMI info, and add the proper
DMI aliases mbASUSPXV (or whatever) so the modules can be autoloaded.
I don't know enough about the current udev module autoloading stuff to
really comment on this, but yes a platform driver could be written which
would generate some kinda fake plug and play message sending a unique mb
identification to udev, and then udev could look this up in a database
and load the proper drivers. We would then however still need a (udev
helper?) script that generates a correct /etc/sensors.conf, which
contains the input pins -> measured items and their scales.
But the biggest problem is building the still needed database, the exact
implementation of the tool is IMHO a lesser problem, I'm sure we can
work this out. If your above idea is doable it might actually be a nice
clean way for the autoconfig tool part.
Regards,
Hans