Re: [PATCH 25/20] sysfs: Only support removing emtpy sysfs directories.
From: James Bottomley
Date: Wed May 27 2009 - 13:08:36 EST
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/