Re: [PATCH 25/20] sysfs: Only support removing emtpy sysfs directories.

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2009-05-27 at 13:01 -0400, Alan Stern wrote:
> On Wed, 27 May 2009, James Bottomley wrote:
> 
> > > I don't understand all the subtle issues here.  In other contexts, the 
> > > solution would be to initialize a refcount to 1 when the target is 
> > > allocated, increment it when a device is added, and decrement it when a 
> > > device is removed or the host is removed.  When the refcount goes to 0, 
> > > the target is deleted.  Why wouldn't this kind of approach work?
> > 
> > Um, well that's exactly how it works (modulo the fact that there are
> > parts of the lifecycle where the ref count is zero, like scanning).
> 
> Why does that happen?  It's reasonable that there should be times 
> during scanning when the target doesn't have any children, but the 
> refcount should still be positive.

By refcount, I mean count of underlying devices.

> >  The
> > problem you're complaining about is that the device ref on the target
> > may take a long time to release, so we can't key the del event on the
> > refcount going to zero, which is what we do today.
> 
> Maybe we should be talking about two separate refcounts: a normal 
> get_device/put_device kref counter for the target's lifetime, and a 
> visibility counter (one for each child device and one overall) which 
> keys the del event and must go to 0 before the host removal finishes.

Um, well, that's roughly how I said we'd have to fix all of this in the
email to hannes ... it would be much easier if we could make a del'd
device visible, but now we have to have different behaviours depending
on whether the host is going away or not.

James