[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4922E622.50401@kernel.org>
Date: Wed, 19 Nov 2008 00:58:26 +0900
From: Tejun Heo <tj@...nel.org>
To: Boaz Harrosh <bharrosh@...asas.com>
CC: Greg KH <greg@...ah.com>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Miklos Szeredi <miklos@...redi.hu>
Subject: Re: [PATCH RESEND] char_dev: add cdev->release() and convert cdev_alloc()
to use it
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. Hmm... if your patches
are gonna go through some public tree, I think we can ask Miklos pull
from the tree too. Guys, what do you think?
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists