From: Randy Dunlap <randy.dunlap@oracle.com>
To: Greg KH <greg@kroah.com>
Cc: Michael Ellerman <michael@ellerman.id.au>,
linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>,
viro@zeniv.linux.org.uk
Subject: Re: [PATCH] Store the relevant miscdevice in file->private_data in misc_open()
Date: Thu, 13 Nov 2008 20:01:47 -0800 [thread overview]
Message-ID: <491CF82B.7040703@oracle.com> (raw)
In-Reply-To: <20081114032313.GB15204@kroah.com>
Greg KH wrote:
> On Fri, Nov 14, 2008 at 01:50:52PM +1100, Michael Ellerman wrote:
>> On Thu, 2008-11-13 at 16:18 -0800, Greg KH wrote:
>>> On Fri, Nov 14, 2008 at 10:54:41AM +1100, Michael Ellerman wrote:
>>>> On Thu, 2008-11-13 at 09:31 -0800, Greg KH wrote:
>>>>> On Thu, Nov 13, 2008 at 03:49:50PM +1100, Michael Ellerman wrote:
>>>>>> Currently it's not easy to share file_operations between multiple
>>>>>> instances of a miscdevice. In order to do this, the device code needs to
>>>>>> store a list of all it's miscdevice instances, and when fops->open() is
>>>>>> called, search the list and find the right device based on the minor
>>>>>> number.
>>>>>>
>>>>>> However the generic miscdevice code already has a list of miscdevices,
>>>>>> and uses this to find the right device in misc_open(). If misc_open()
>>>>>> would store the miscdevice it found in file->private_data, then the
>>>>>> device code wouldn't need to worry about storing it's own separate list
>>>>>> and searching that as well.
>>>>>>
>>>>>> The rest of the miscdevice code does not use file->private_data, so the
>>>>>> device code is still free to use file->private_data for something else
>>>>>> if it wants to.
>>>>>>
>>>>>> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
>>>>> Do you have a follow-on patch for some misc device using code that would
>>>>> take advantage of this change?
>>>> Ah, good point. I do, but not for upstream :/
>>> Hm, then I have to ask why should we take this change?
>> Because it's seems like a good idea.
>
> You know we don't make changes to core code for drivers that aren't in
> the main tree, this is not a new thing...
>
>>> And why would the driver not be availble for upstream to take?
>> Because it's a hacky pile of crud, and it's for unreleased and
>> non-existent hardware.
>
> That's what the drivers/staging/ tree is for, send it on over to me and
> I'll add it to that location.
for non-existent hardware?? that's not a good plan.
--
~Randy
next prev parent reply other threads:[~2008-11-14 4:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-13 4:49 [PATCH] Store the relevant miscdevice in file->private_data in misc_open() Michael Ellerman
2008-11-13 17:31 ` Greg KH
2008-11-13 23:54 ` Michael Ellerman
2008-11-14 0:18 ` Greg KH
2008-11-14 2:50 ` Michael Ellerman
2008-11-14 3:23 ` Greg KH
2008-11-14 4:01 ` Randy Dunlap [this message]
2008-11-14 4:15 ` Greg KH
2008-11-14 4:58 ` Michael Ellerman
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=491CF82B.7040703@oracle.com \
--to=randy.dunlap@oracle.com \
--cc=akpm@osdl.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=michael@ellerman.id.au \
--cc=viro@zeniv.linux.org.uk \
/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.