Greg KH wrote:
>On Tue, Aug 16, 2005 at 08:34:24AM -0500, Michael E Brown wrote:
>
>
>>On Tue, 2005-08-16 at 01:16 -0700, Greg KH wrote:
>>
>>
>>>No, export this data properly through sysfs like all other temperature
>>>and sensor data is. Don't create a new one, no matter how much you
>>>would like to keep from changing kernel code in the future for new
>>>hardware.
>>>
>>>
>>This driver is not trying to create a new way to do sensor and monitor
>>data. This just happens to be a side effect of the main use case.
>>
>>
>
>But it's probably a main use case for a lot of users daily experience,
>right?
>
>
>
No. And after this feedback, I'll be trying to make sure this doesn't
happen.
There are two main users of this driver (dcdbas) at this point.
1) libsmbios.
The main use of this driver by libsmbios will be to set BIOS F2
options. Based on your feedback, I will _NOT_ be implementing any
fan/sensor functionality in libsmbios, but will work with the lmsensors
guys to do this instead. I only originally mentioned it because I
thought it would be useful. My eyes have now been opened as to the best
way to do this, and we will do it that way.
2) Dell OpenManage
The main use of this driver by openmanage will be to read the System
Event Log that BIOS keeps. Here are some other random relevant points:
A) The sensor functions available through Dell SMI calls are only on
laptops at this point.
B) OpenManage is not supported on laptops (server only)
C) OpenManage is transistioning to use openipmi to do all
sensor-related stuff, so there is no need to use SMI.
All this adds up to the fact that neither of the two official Dell apps
that use this Dell SMI driver will be using this driver for _ANY_ type
of sensor functionality, and there is no danger at all of either of
these apps ever growing this functionality. So out of the many SMI
functions available for use using this driver, only about 3 or 4 would
be commonly used officially by Dell.
In the meantime, as a community service, I have offered up libsmbios to
document the other many functions available using SMI to anybody who
thought they would be useful (as several people have privately emailed
me). Based on the availability of this extra functionality (sensors) the
whole submission of dcdbas driver is being questioned. I would like to
re-iterate at this point what I said in one of my first emails.
Everything that you can do using this dcdbas driver can already be done
"under the covers" in userspace with the right incantations. (ie. set
processor affinity, pick a BIOS reserved area as your physical buffer).
What you get by using the dcdbas driver is an auditable entry point in
the kernel for anybody wanting to do one of these SMI calls. If the
dcdbas driver is accepted, all Dell software that does SMIs will use it.
Then, anybody who is curious about which SMI calls that Dell software is
performing can simply add logging hooks to dcdbas to syslog the contents
of each buffer passed. People who think they are making things "safer"
by restricting userspace access to SMIs are only deluding themselves.
>>>>For example, we already have at least one buggy implementation of this
>>>>exact stack in the kernel as the i8k driver. The i8k driver was reverse-
>>>>engineered and works, but it does not follow the spec at all, and so is
>>>>subject to major breakage if the BIOS changes. With dcdbase + libsmbios,
>>>>we can write this _correctly_, and in such a way that it follows the
>>>>spec and will not break on BIOS updates.
>>>>
>>>>
>>>No, fix the i8k driver as you have access to the specs. It was there
>>>first.
>>>
>>>
>>Ok.
>>
>>
>
>On second thought, after looking at that code, forget it, just do
>something new with the proper hwmon interface instead.
>
>
Ok.
>>>>Each function would have to take into account the specific calling
>>>>requirements of that specific function.
>>>>
>>>>
>>>Again, no different from any other sensor driver.
>>>
>>>
>>Again, this driver is not a sensor driver.
>>
>>
>
>You provide sensor data, hence...
>
>
>
I cannot go back and undo the way BIOS has designed this interface. It
just so happens that by providing a generic way to get the data I want,
you also can get at some other, unrelated stuff. We promise we won't use
this interface to get that unrelated stuff, (as silly as that sounds).
>>For some odd reason, our customers have less concerns with updating a
>>userspace library.
>>
>>
>
>For a library like this, they should be just as concerned, as you have a
>direct hook into their hardware, with the ability to break it just as
>easily as a kernel update.
>
>
>
Not really. None of the SMI calls that I am aware of has any ability to
affect the running of the system with the exception of the Radio control
and Display switching calls. It would most likely be best to give the
docs for these to the appropriate driver people to implement in their
drivers.
Most of the SMI options affect boot stuff, like boot order. None of the
SMI calls interface with the kernel at all. I don't really see how any
of the calls available through this interface can do any damage to hardware.
And just to re-iterate one more time, we can already directly hook into
hardware from userspace without any kernel auditing. We are just trying
to set this out on the table for everybody to see.
--
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
