From: Tejun Heo <tj@kernel.org>
To: Greg KH <greg@kroah.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RESEND] char_dev: add cdev->release() and convert cdev_alloc() to use it
Date: Thu, 28 Aug 2008 19:55:39 +0200 [thread overview]
Message-ID: <48B6E69B.1090800@kernel.org> (raw)
In-Reply-To: <20080828174807.GA18461@kroah.com>
Greg KH wrote:
>> The problem is not the device to talk to CUSE (/dev/cuse as in
>> /dev/fuse), for which module refcount and device refcount match fine.
>> But the whole point of CUSE is allowing CUSE clients to create arbitrary
>> character devices, so in addition to /dev/cuse which clients use to talk
>> to CUSE, CUSE hosts character devices for its clients and they come and
>> go dynamically and thus requires proper lifetime management.
>
> That's fine, it's just like a USB device that uses a cdev, right? Or a
> PCI device, or any other type of device that can come and go independant
> of the cdev or module lifespan.
>
> So, you tie the cdev lifespan to the module lifespan with the
> MODULE_OWNER in the file operations. As the cuse.ko module will own the
> cdev, it can handle that reference, and it can not be removed as long as
> userspace has the cdev open, right?
>
> It really isn't any different from any other type of removable device
> (i.e. any type of device...)
Ah.. right, but taking cdev refcount out of the picture requires adding
'severing' operation on cdev f_ops, which certainly is doable but isn't
it just cleaner to make cdev follow the usual lifetime management rules?
An object which is referenced counted requires ->release if it's gonna
be used in any non-simplistic way.
Thanks.
--
tejun
next prev parent reply other threads:[~2008-08-28 17:57 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 [this message]
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
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=48B6E69B.1090800@kernel.org \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.