After examining the code to figure out the extent of the WAR in BZ 439246, it
looks like I found a new bug :(

drivers/acpi/bay.c is built in and registers a notifier for bay events,
bay_events().  This handler is *very* simple and printks an event message and 
indicates that a status change has occurred through a uevent file.  AFAICT,
there is no way to determine what the status change actually was with the bay.c
driver.

drivers/acpi/ibm_acpi is loaded and creates sysfs files (which are the files we
are currently using to manually interact with the device) and then attempts to
register its own handler -- this fails because bay.c has already registered a
handler.

This results in the odd situation that RHEL5 is actually using TWO drivers for
one device.

ibm_acpi.c is not upstream so upstream doesn't have this situation.

Thinking of doing the following:

a) in bay.c introducing a blacklist file so that additional vendor drivers can
override the generic bay.c driver.
b) introducing a command line option so that other unknown systems can override.

P.