Re: [RFC][PATCH 2.6.13-rc6] add Dell Systems Management Base Driver (dcdbas) with sysfs support

[<Michael_E_Brown@Dell.com>]

>> +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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/