From: Salah Triki <salah.triki@gmail.com>
To: Felix Kuehling <felix.kuehling@amd.com>
Cc: "Alex Deucher" <alexander.deucher@amd.com>,
"Christian König" <christian.koenig@amd.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm: amdkfd: Replace (un)register_chrdev() by (unregister/alloc)_chrdev_region()
Date: Fri, 7 Mar 2025 20:10:46 +0100 [thread overview]
Message-ID: <Z8tEti/ZRbx5pt5M@pc> (raw)
In-Reply-To: <a5b1d94e-30ee-411c-88f5-1e340068220c@amd.com>
On Wed, Mar 05, 2025 at 07:18:33PM -0500, Felix Kuehling wrote:
>
> On 2025-03-05 16:08, Salah Triki wrote:
> > Replace (un)register_chrdev() by (unregister/alloc)_chrdev_region() as
> > they are deprecated since kernel 2.6.
>
> Where is that information coming from? I see __register_chrdev documented in
> the current kernel documentation. I see no indication that it's deprecated:
> https://docs.kernel.org/core-api/kernel-api.html#c.__register_chrdev
>
In the book "Linux Device Drivers" 3ed of J. Corbet and al. (2005), it
is indicated that using register_chrdev() is the old way to register
char drivers, the new code should not use this interface, it should
instead use the cdev interface.
>
> > alloc_chrdev_region() generates a
> > dev_t value, so replace the kfd_char_dev_major int variable by the
> > kfd_char_dev_id dev_t variable and drop the MKDEV() call. Initialize a
> > cdev structure and add it to the device driver model as register_chrdev()
> > used to do and since alloc_chrdev_region() does not do it. Drop the
> > iminor() call since alloc_chrdev_region() allocates only one minor number.
> > On error and in the module exit function, remove the cdev structure from
> > the device driver model as unregister_chrdev() used to do.
>
> Sounds complicated. Your patch seems to open-code a bunch of details that
> are neatly hidden inside register_chrdev. Why would I want all that detail
> in my driver? I don't see an obvious advantage.
>
register_chrdev() registers 256 minor numbers, calling it will result in
calling kmalloc_array(256, sizeof(struct probe), GFP_KERNEL) whereas
calling alloc_chrdev_region() with count parameter equals to 1, which is
the number of minor numbers requested, will result in calling
kmalloc_array(1, sizeof(stuct probe), GFP_KERNEL).
Best Regards,
Salah Triki
next prev parent reply other threads:[~2025-03-08 9:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-05 21:08 [PATCH] drm: amdkfd: Replace (un)register_chrdev() by (unregister/alloc)_chrdev_region() Salah Triki
2025-03-06 0:18 ` Felix Kuehling
2025-03-07 19:10 ` Salah Triki [this message]
2025-03-10 12:11 ` Christian König
2025-03-10 15:19 ` Salah Triki
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=Z8tEti/ZRbx5pt5M@pc \
--to=salah.triki@gmail.com \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=felix.kuehling@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=simona@ffwll.ch \
/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.