Re: [PATCH 3/3] rust: miscdevice: adjust the rust_misc_device sample to use RegistrationData.

[Christian Schrefl <chrisi.schrefl@gmail.com>]

On 24.01.25 12:37 PM, Alice Ryhl wrote:
> On Fri, Jan 24, 2025 at 12:22 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
>>
>> On Fri, Jan 24, 2025 at 11:39:23AM +0100, Alice Ryhl wrote:
>>> On Fri, Jan 24, 2025 at 11:34 AM Greg Kroah-Hartman
>>> <gregkh@linuxfoundation.org> wrote:
>>>>
>>>> On Fri, Jan 24, 2025 at 10:42:53AM +0100, Alice Ryhl wrote:
>>>>> On Fri, Jan 24, 2025 at 9:06 AM Greg Kroah-Hartman
>>>>> <gregkh@linuxfoundation.org> wrote:
>>>>>>
>>>>>> On Fri, Jan 24, 2025 at 08:29:38AM +0100, Alice Ryhl wrote:
>>>>>>> On Thu, Jan 23, 2025 at 6:57 PM Christian Schrefl
>>>>>>> <chrisi.schrefl@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Hi Alice
>>>>>>>>
>>>>>>>> On 21.01.25 4:40 PM, Alice Ryhl wrote:
>>>>>>>>> On Sun, Jan 19, 2025 at 11:11 PM Christian Schrefl
>>>>>>>>> <chrisi.schrefl@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Share the mutex stored in RustMiscDevice between all instances using an Arc
>>>>>>>>>> and the RegistrationData of MiscDeviceRegistration.
>>>>>>>>>>
>>>>>>>>>> This is mostly to Demonstrate the capability to share data in this way.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Christian Schrefl <chrisi.schrefl@gmail.com>
>>>>>>>>>
>>>>>>>>> This change causes all open files to share the same value, instead of
>>>>>>>>> it being per-fd.
>>>>>>>>
>>>>>>>> I know, if that is unwanted I'm fine with dropping this patch,
>>>>>>>> it is mostly here to show how patch 2 can be used.
>>>>>>>
>>>>>>> Perhaps instead of changing the per-fd value, we could add a new
>>>>>>> shared value? E.g., it could have a counter for the number of open
>>>>>>> files.
>>>>>>
>>>>>> Counters don't work, sorry (think about dup() for file handles), please,
>>>>>> either make it per-file handle, or a "global" thing for the specific
>>>>>> object, don't attempt to count open/release calls, the vfs does this for
>>>>>> us already.
>>>>>
>>>>> I mean, it's just for an example, shrug. It could also be another
>>>>> ioctl that updates the shared value.
>>>>
>>>> Sure, but the number of times I've seen sample code copied into "real"
>>>> code is way too high.  Also, getting people to stop thinking they even
>>>> can count the number of open file handles is a good idea as that's an
>>>> extremely common "anti-pattern" in way too many drivers even today (i.e.
>>>> if you try to count open calls, or even restrict the number of open
>>>> calls to attempt some sort of control, you're doing it totally wrong.)
>>>
>>> Fair point. Do you have good ideas for some data we could put in the
>>> data shared by all instances of the file?
>>
>> "shared_cookie"?  Read/write and let readers and writers access it.  But
>> I thought that was what the misc example did already, but I might be
>> getting confused here, it's been a while since I looked at the code,
>> sorry.
> 
> Makes sense to me.
> 
> The existing cookie is per `struct file`, but this series is about
> making it possible to have data shared by all instances of a
> miscdevice. But having two cookies, one that is per `struct file` and
> one that is global makes sense to me.

I've Implemented one shared (Every instance) and one unique(One for every FD)
data.

Christian