lkml.org 
[lkml]   [2005]   [Aug]   [16]   [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
    Date
    From
    > -----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/

    \
     
     \ /
      Last update: 2005-08-17 01:51    [W:0.023 / U:30.264 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site