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

[Kyle Moffett <mrmacman_g4@mac.com>]

On Aug 15, 2005, at 16:05:22, Doug Warzecha wrote:
> This patch adds the Dell Systems Management Base Driver with sysfs  
> support.
> +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?

> +Host Control Action
> +
> +Dell OpenManage supports a host control feature that allows the  
> administrator
> +to perform a power cycle or power off of the system after the OS  
> has finished
> +shutting down.  On some Dell systems, this host control feature  
> requires that
> +a driver perform a SMI after the OS has finished shutting down.
> +
> +The driver creates the following sysfs entries for systems  
> management software
> +to schedule the driver to perform a power cycle or power off host  
> control
> +action after the system has finished shutting down:
> +
> +/sys/devices/platform/dcdbas/host_control_action
> +/sys/devices/platform/dcdbas/host_control_smi_type
> +/sys/devices/platform/dcdbas/host_control_on_shutdown
How is this different from shutdown() or reboot()?  What exactly is  
smi_type used
for?  Please provide better documentation on how to use this and what  
it does.
If this is supposed to be used with the RBU code to trigger a BIOS  
update, then
why not integrate it into one kernel driver that receives firmware,  
loads it into
the BIOS, and properly resets the machine at powerdown?  I think  
PowerPC does a
similar thing with OpenFirmware flash memory.  When I change the  
default boot
device or other firmware environment, I get a message from the kernel  
upon
shutdown:
Erasing <BRAND> flash bank 1...
Writing <BRAND> flash bank 1...

Would not a similar system work for Dell?  It would be far simpler to  
use than
the current mess of patches you've proposed.  If done properly, I  
could even
do this:

cat firmware-with-checksum.img >/sys/devices/platform/dellbios/ 
firmware_upgrade
Then an ordinary system reboot or shutdown would automatically use  
the SMI and
host-control-action to upgrade the firmware and shutdown or reboot,  
instead of
the normal ACPI shutdown and reboot code.

Cheers,
Kyle Moffett

--
Somone asked me why I work on this free (http://www.fsf.org/philosophy/)
software stuff and not get a real job. Charles Shultz had the best  
answer:
"Why do musicians compose symphonies and poets write poems? They do  
it because
life wouldn't have any meaning for them if they didn't. That's why I  
draw
cartoons. It's my life."
  -- Charles Shultz


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