>> +On some Dell systems, systems management software must access
certain
>> +management information via a system management interrupt (SMI).
>> The SMI data
>> +buffer must reside in 32-bit address space, and the physical
>> address of the
>> +buffer is required for the SMI. The driver maintains the memory
>> required for
>> +the SMI and provides a way for the application to generate the SMI.
>> +The driver creates the following sysfs entries for systems
management
>> +software to perform these system management interrupts:
>
> Why can't you just implement the system management actions in the
kernel
> driver? This is tantamount to a binary SMI hook to userspace. What
> functionality does this provide on a dell system from an
administrator's
> point of view?
Kyle,
I'm sure that not everybody agrees with the whole concept of SMI
calls. Nevertheless, these calls exist, and in order to have a complete
systems-management solution, we have to provide a way to do SMI calls.
Now, we have developed a way to do these SMI calls from userspace
without
kernel support, but we are trying to be community-friendly and show our
hooks in the open, rather than trying to sneak them in under the covers.
You might not like the concept of a generic hook for SMI calls
in
the kernel, but the alternatives are hardly better. One alternative is
the already-mentioned method that we do things under the covers in
userspace. Another alternative is that we write separate kernel code for
each and every SMI call that exists in the Dell BIOS. The second
alternative is not entirely feasible. We have over 60 SMI functions, and
we would have to write a kernel-mode wrapper for each and every one. I
hope you agree that code that doesn't exist is less buggy than code that
is, and that code that is in userspace is a whole lot less likely to
cause
a kernel crash than code that is in the kernel. We are trying to keep
our
kernel bloat down. We don't really think that customers of IBM or HP
really
want their Red Hat kernels loaded down with a bunch of Dell-only code.
Additionally, we are releasing an open source library (GPL/OSL
dual
license) that can use these hooks to perform many systems management
functions in userspace. See http://linux.dell.com/libsmbios/main/. We
should have code in libsmbios to do SMI using this driver within about
two
weeks. We currently writing the SMI hooks in libsmbios using this
posted
version of the driver. I am the maintainer of this project, and it is my
goal
to have code in libsmbios for every Dell SMI call.
Dell is not trying to use this driver as a method of inserting
binary
blobs into the kernel, nor are we trying to subvert kernel security by
implementing this driver. We are simply trying to get all of our systems
management software into the kernel as open source drivers. This
represents
a fundamental shift in philosophy from the Dell systems-management team
from
our previous binary-only driver approach.
We would welcome feedback on a better way to implement this
driver in
the kernel, but the fact remains that we have to have a way to do this,
and
we are open-sourcing all of the code necessary to get this done.
--
Michael Brown
-
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/
