[lkml]   [2005]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH 2.6.13-rc6] add Dell Systems Management Base Driver (dcdbas) with sysfs support
>> +On some Dell systems, systems management software must access
>> +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
>> +software to perform these system management interrupts:
> Why can't you just implement the system management actions in the
> driver? This is tantamount to a binary SMI hook to userspace. What
> functionality does this provide on a dell system from an
> point of view?

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
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
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
a kernel crash than code that is in the kernel. We are trying to keep
kernel bloat down. We don't really think that customers of IBM or HP
want their Red Hat kernels loaded down with a bunch of Dell-only code.

Additionally, we are releasing an open source library (GPL/OSL
license) that can use these hooks to perform many systems management
functions in userspace. See We
should have code in libsmbios to do SMI using this driver within about
weeks. We currently writing the SMI hooks in libsmbios using this
version of the driver. I am the maintainer of this project, and it is my
to have code in libsmbios for every Dell SMI call.

Dell is not trying to use this driver as a method of inserting
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
a fundamental shift in philosophy from the Dell systems-management team
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,
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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-08-16 01:02    [W:0.045 / U:7.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site