Re: ibm-acpi bay and acpi generic bay convergence

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 19 Mar 2007, Kristen Carlson Accardi wrote:
> Henrique de Moraes Holschuh <hmh@xxxxxxxxxx> wrote:
> > So the first step is to improve is_ejectable_bay.  What reason did you have
> > to limit it only to devices where is_ata returns true?  Is there a reason
> > why anything that is not a dock and is ejectable should not be handled as a
> > bay ?
> 
> The only reason the generic bay driver is limited to only ata devices is
> simply because that's all I decided to implement for the first revision
> of the driver.  So, the perfect time to expand is now :).
> 
> Yes - there's a reason why we can't just blindly claim anything ejectable
> that isn't a dock.  PCI Hotplug for example.  What I think would be
> ideal would be if the bay driver could register for events on anything
> ejectable iff no other driver has claimed them.  I couldn't find an easy
> way to do this last time I checked (months ago).  Seems like we might have
> to change the way ACPI notifications are sent - I was hoping they could be
> changed to be more like interrupts - so that you could have a return code
> from the notification call that indicates whether the driver handled the
> event or not - and allow multiple drivers to register for the same event.
> This would also make it possible to eliminate weird stuff like what I'm doing
> with the dock driver to allow the bay driver to get dock notifications -
> the bay driver could just check to see if it's dependent on another object
> using _EJD and then request events on that object as well.

I like this idea quite a lot.  Only, we probably need to not only support a
"walk until someone consumes the event" chain, but also a "notify every
interested party that an event has happened and was consumed/was not
consumed" functionality.  You also may wany the "consume event" chain to
understand priorities when inserting drivers in it, so that you can be a
"well, if nobody else wants it..." consumer or a "me! me! me!" consumer.

It is not complete (it doesn't allow ibm-acpi to talk to bay and dock
without using module dependencies for example), but it is quite a good
start.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
ibm-acpi-devel mailing list
ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

[Index of Archives]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Photo]     [Yosemite Photos]     [Yosemite Advice]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux