Re: 2.6.25 semantic change in bay handling?

[Holger Macht <hmacht@suse.de>]

On Di 06. Mai - 19:48:28, Matthew Garrett wrote:
> On Tue, May 06, 2008 at 08:36:12PM +0200, Holger Macht wrote:
> > Hi Matthew,
> > 
> > ( Please TO or CC hmacht@suse.de ! )
> 
> Then stop setting Mail-Followup-To: :)
> 
> > > Hm. I'm not absolutely certain about this. Do we get a bus check 
> > > notification after the dock has been removed? If so, I think it ought to 
> > > be handled the same way as the internal bay (ie, signal userspace and 
> > > let it clean up and destroy the device - if it fails to do so, then 
> > > destroy the device when the dock is actually removed, by catching the 
> > > bus/device check, calling the _STA method on the bay and destroying the 
> > > device if it's present)
> > 
> > libata is notified through the dock driver when a dock event occurs, just
> > before the dock driver undocks, giving no time to userspace to clean
> > up. libata doesn't receive an additional acpi bay event.
> 
> That's the current situation, I'm not sure it's ideal. But I'll skip 

What exactly do you think is not ideal?

> worrying about that until I've actually got some hardware to work out 
> how to do it properly :)

Maybe this is what you're thinking of?:
  http://marc.info/?l=linux-acpi&m=121009411900390&w=2

> 
> > >>  2. Bay event: libata signals a BAY_EVENT through uevent, userspace writes
> > >>     	       1 to /sys/.../device/delete
> > 
> > > In the case of an eject request, yes. In the case of a bus or device 
> > > check, we should call _STA and then delete/hotplug the device as 
> > > appropriate.
> > 
> > Yes.
> 
> Excellent. I /think/ the patch I sent earlier basically does this - 
> you'll want to register a separate callback for the dock event in that 
> case, though.

I'll take a look the following days, thanks.

Regards,
	Holger