public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Tejun Heo <tj@kernel.org>
Cc: Boaz Harrosh <bharrosh@panasas.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Miklos Szeredi <miklos@szeredi.hu>
Subject: Re: [PATCH RESEND] char_dev: add cdev->release() and convert cdev_alloc() to use it
Date: Wed, 19 Nov 2008 21:54:50 -0800	[thread overview]
Message-ID: <20081120055450.GA10821@kroah.com> (raw)
In-Reply-To: <4922E622.50401@kernel.org>

On Wed, Nov 19, 2008 at 12:58:26AM +0900, Tejun Heo wrote:
> Hello,
> 
> Boaz Harrosh wrote:
> > I just saw this thread for the first time and it left me confused.
> > What was the final verdict. Is this patch going in at the end?
> > Which incarnation of it? is there a public git tree I can try?
> 
> Yes it is and as posted and no there isn't no public git tree yet, I was
> planning on pushing it through Miklos' tree.
> 
> > The reason I ask is because I have just the same principal work in one of
> > my test trees. What I have is a Filesystem, osdfs, that is mounted
> > on an OSD scsi-device, which is a char-device. Now the osdfs when mounting
> > an OSD device does not use __open, like user mode it needs some kernel
> > reference counting to keep the char-device up. On the other hand
> > the actual teardown and unmap of the char-device is done from the scsi-ml
> > remove vector. So just like in sd, sr and other scsi ULDs I need to unmap
> > the device but keep the memory allocated and available until the last reference.
> > All this is usually done using the Release() of the block-device. But for me
> > I only have a char-device. Currently what I had to do is keep another kref
> > to govern the device's lifecycle and sync every thing together. A Release() at
> > the char-dev would let me reuse what's there and let me clean all that code up.
> > 
> > While Investigating the problem and compering what was done on the block-device
> > side, I've seen more then a few places that private reference counting could be
> > dropped completely, and the char-dev could be used. Off my head some of these places
> > are: 
> > 	- UBI used by UBIFS 
> > 	- sg.c which does not have a Kernel user but needs it's char device until
> > 	  scsi-Remove and/or __close()
> > 
> > and other places as well.
> 
> Hmmm... if you can use this change, I think you can push it through
> whatever tree you push patches through, things can be taken care of when
> merging or we can put it in Greg's tree and ask Miklos to pull from the
> tree first but Greg doesn't keep a stable tree.

I don't keep a stable tree?  What do you mean?  It's a quilt tree, and
it does get included in -next, so I think it does work :)

Send it to me again and I'll push it through my tree if no one else
objects.

thanks,

greg k-h

  parent reply	other threads:[~2008-11-20  6:13 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-28 16:36 [PATCH RESEND] char_dev: add cdev->release() and convert cdev_alloc() to use it Tejun Heo
2008-08-28 16:47 ` Greg KH
2008-08-28 16:56   ` Tejun Heo
2008-08-28 17:38     ` Greg KH
2008-08-28 17:44       ` Tejun Heo
2008-08-28 17:48         ` Greg KH
2008-08-28 17:55           ` Tejun Heo
2008-08-28 18:17             ` Greg KH
2008-11-13  8:58               ` Tejun Heo
     [not found]                 ` <492136F5.8010903@kernel.org>
     [not found]                   ` <20081117171717.GB31306@kroah.com>
     [not found]                     ` <49221CE8.1050402@kernel.org>
2008-11-18  1:40                       ` Tejun Heo
2008-11-18 13:44                         ` Boaz Harrosh
2008-11-18 15:58                           ` Tejun Heo
2008-11-19 17:59                             ` Miklos Szeredi
2008-11-20  5:54                             ` Greg KH [this message]
2008-11-20  6:28                               ` Tejun Heo
2008-11-20 11:45                                 ` Tejun Heo

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=20081120055450.GA10821@kroah.com \
    --to=greg@kroah.com \
    --cc=bharrosh@panasas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --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