Bill Nottingham wrote:
Hans de Goede (j.w.r.degoede@xxxxxx) 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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
