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

[<Michael_E_Brown@Dell.com>]

> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com] 
> Sent: Tuesday, August 16, 2005 6:24 PM
> To: Brown, Michael E
> Cc: mrmacman_g4@mac.com; linux-kernel@vger.kernel.org; 
> Warzecha, Douglas; Domsch, Matt
> Subject: Re: [RFC][PATCH 2.6.13-rc6] add Dell Systems 
> Management Base Driver (dcdbas) with sysfs support
> 
> 
> On Tue, Aug 16, 2005 at 06:11:13PM -0500, 
> Michael_E_Brown@Dell.com wrote:
> > 
> >     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.
> 
> Ok, sounds good.
> 
> Hm, what about my code comments, they seem to have been lost 
> in the noise...

No, they are not lost. Doug is working on them and will send you
something shortly (EOD today).

> 
> > 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.
> 
> So, this whole driver is not needed at all?  It can all be 
> done from userspace?  If so, then this shouldn't be added to 
> the kernel tree.

Several reasons:

A) Auditability: we don't do "secret" SMI calls behind people's backs.
This is an issue for some of our larger customers. This also provides a
legitimate reason that I can use to justify to management publicly
documenting the rest of the SMI calls that are not in use by our
software. Things like: "Hey, SomeBigDellCustomer wants to know what Dell
is doing with the open source dcdbas driver and all of the other SMI
function docs" pull a lot of weight.

B) Safety: It is easier to provide a single API with well defined
semantics so there are no race conditions when multiple programs try to
do SMI at the same time. SMI from userspace can be tricky, and I want to
make it easy to get right. Things like finding an usused BIOS reserved
area and coordinating access between multiple programs can be difficult.
Additionally, finding an area large enough to hold everything for the
larger SMI calls is tricky (ie. depends on which system, BIOS memory
layout, etc. Very difficult to safely code for and mostly not worth the
effort if we can get this driver in).

C) host control actions need to happen in kernel at shutdown, so that
part of the driver needs to be in the kernel. (this part isn't the part
that provides generic SMI stuff to userspace)

--
Michael
-
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/