public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Hannes Reinecke <hare@suse.de>,
	Kay Sievers <kay.sievers@vrfy.org>,
	SCSI development list <linux-scsi@vger.kernel.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	Tejun Heo <tj@kernel.org>,
	Cornelia Huck <cornelia.huck@de.ibm.com>,
	linux-fsdevel@vger.kernel.org,
	"Eric W. Biederman" <ebiederm@aristanetworks.com>
Subject: Re: [PATCH 25/20] sysfs: Only support removing emtpy sysfs directories.
Date: Wed, 27 May 2009 19:44:23 +0000	[thread overview]
Message-ID: <1243453463.6067.63.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0905271356090.15690-100000@iolanthe.rowland.org>

On Wed, 2009-05-27 at 14:07 -0400, Alan Stern wrote:
> On Wed, 27 May 2009, James Bottomley wrote:
> 
> > By refcount, I mean count of underlying devices.
> 
> Does that mean only registered devices, or does it include devices 
> which are unregistered but not yet released?

All devices ... scsi_device has to has a target parent before its
usable.

> > > >  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,
> 
> I don't follow.  Why would you want to delete a target before the host
> is removed and then make it visible again later?  Because it doesn't
> have any underlying devices at the moment but may gain some later on?

Perhaps I haven't made the problem clear enough.  You only want early
del if the host is going away, otherwise the target might be reused and
it can't be if you've called del on it.  So there needs to be an
integration into the host lifecycle in some form.

James



  reply	other threads:[~2009-05-27 19:44 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <ac3eb2510905260927we3c748akbbcaf3f3ac1da096@mail.gmail.com>
2009-05-26 19:29 ` [PATCH 25/20] sysfs: Only support removing emtpy sysfs directories Alan Stern
2009-05-26 21:09   ` James Bottomley
2009-05-26 21:13     ` Kay Sievers
2009-05-26 21:56       ` Alan Stern
2009-05-26 22:03         ` Kay Sievers
2009-05-26 23:49           ` James Bottomley
2009-05-27  0:02             ` Kay Sievers
2009-05-27  2:17               ` Alan Stern
2009-05-27 11:35                 ` Hannes Reinecke
2009-05-27 16:01                   ` James Bottomley
2009-05-27 16:16                     ` Alan Stern
2009-05-27 16:24                       ` James Bottomley
2009-05-27 17:01                         ` Alan Stern
2009-05-27 17:08                           ` James Bottomley
2009-05-27 18:07                             ` Alan Stern
2009-05-27 19:44                               ` James Bottomley [this message]
2009-05-27 20:40                                 ` Alan Stern
2009-05-27 20:49                                   ` James Bottomley
2009-05-27 21:31                                     ` Alan Stern
2009-05-27 21:42                                       ` James Bottomley
2009-05-27 22:15                                         ` Alan Stern
2009-05-27 22:22                                           ` James Bottomley
2009-05-28 15:24                                             ` Alan Stern
2009-05-28 15:45                                               ` Eric W. Biederman
2009-05-28 17:51                                                 ` Alan Stern
2009-05-28 18:21                                               ` James Bottomley
2009-05-28 20:02                                                 ` Alan Stern
2009-05-28 20:10                                                   ` James Bottomley
2009-05-28 21:04                                                     ` Alan Stern
2009-05-29 12:32                                                       ` Hannes Reinecke
2009-05-29 20:08                                                     ` Alan Stern
2009-05-27 18:00                 ` Eric W. Biederman
2009-05-27 18:15                   ` Alan Stern
2009-05-27 18:24                     ` Eric W. Biederman
2009-05-27 21:38                       ` Alan Stern
2009-05-27 22:06                         ` Eric W. Biederman
2009-05-27 22:18                           ` Alan Stern
2009-05-26 21:39     ` Alan Stern
     [not found] <1243252896.4853.9.camel@poy>
2009-05-25 15:49 ` Alan Stern
2009-05-25 18:19   ` Kay Sievers
2009-05-25 20:14     ` Alan Stern

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1243453463.6067.63.camel@localhost.localdomain \
    --to=james.bottomley@hansenpartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=cornelia.huck@de.ibm.com \
    --cc=ebiederm@aristanetworks.com \
    --cc=ebiederm@xmission.com \
    --cc=gregkh@suse.de \
    --cc=hare@suse.de \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox