From: John Hubbard <jhubbard@nvidia.com>
To: "Mika Penttilä" <mpenttil@redhat.com>, "Jason Gunthorpe" <jgg@ziepe.ca>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
apopple@nvidia.com, rcampbell@nvidia.com, vbabka@suse.cz
Subject: Re: [PATCH v2] mm/hmm/test: simplify hmm test code: use miscdevice instead of char dev
Date: Thu, 17 Mar 2022 19:58:25 -0700 [thread overview]
Message-ID: <b3d5e596-adce-20b5-73cc-89c07917082f@nvidia.com> (raw)
In-Reply-To: <10fb1261-f22f-8e21-4056-166c283e26f2@redhat.com>
On 3/17/22 19:34, Mika Penttilä wrote:
> On 17.3.2022 16.15, Jason Gunthorpe wrote:
>> On Thu, Mar 17, 2022 at 08:58:52AM +0200, Mika Penttilä wrote:
>>> @@ -1225,7 +1232,11 @@ static int dmirror_device_init(struct dmirror_device
>>> *mdevice, int id)
>>>
>>> cdev_init(&mdevice->cdevice, &dmirror_fops);
>>> mdevice->cdevice.owner = THIS_MODULE;
>>> - ret = cdev_add(&mdevice->cdevice, dev, 1);
>>> + device_initialize(&mdevice->device);
>>> + dev_set_name(&mdevice->device, "%s", dmirror_device_names[id]);
>>> + mdevice->device.devt = dev;
>>> +
>>> + ret = cdev_device_add(&mdevice->cdevice, &mdevice->device);
>>> if (ret)
>>> return ret;
>>
>> Right, miscdev isn't that helpful in the end..
>>
>> Jason
>>
>
> To wrap up, I could send a v3 formal patch with either this cdev way or the miscdev way.. Both
> eliminate the user space /proc/devices parsing and mknod'ing. Jason brought up concerns using
> miscdevice like this, although for this case it works correctly. miscdevice also provides a little
> more cleanup and simpler code, but the difference is not huge. So what do people prefer?
>
No strong preference from me either way, but I would like to bottom on
the potential problems with using misdevice. The fact that miscdevice is
misused in other drivers does not seem like a reason that it must be not
used here...Jason, after Mika's explanation, what's your latest
assessment?
In other words, given that the usage here is correct, is there some
reason that miscdevice is still a poor design fit? Is cdev_device_add()
a better choice here, for design reasons?
Also, is there any change that could or should be made to miscdevice,
that you have in mind?
thanks,
--
John Hubbard
NVIDIA
next prev parent reply other threads:[~2022-03-18 2:58 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-11 3:30 mpenttil
2022-03-11 6:15 ` John Hubbard
2022-03-11 6:18 ` Mika Penttilä
2022-03-14 18:24 ` Jason Gunthorpe
2022-03-15 3:22 ` Mika Penttilä
2022-03-15 18:39 ` Jason Gunthorpe
2022-03-17 5:47 ` Mika Penttilä
2022-03-17 6:58 ` Mika Penttilä
2022-03-17 14:15 ` Jason Gunthorpe
2022-03-18 2:34 ` Mika Penttilä
2022-03-18 2:58 ` John Hubbard [this message]
2022-03-18 12:40 ` Jason Gunthorpe
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=b3d5e596-adce-20b5-73cc-89c07917082f@nvidia.com \
--to=jhubbard@nvidia.com \
--cc=apopple@nvidia.com \
--cc=jgg@ziepe.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mpenttil@redhat.com \
--cc=rcampbell@nvidia.com \
--cc=vbabka@suse.cz \
/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