From: Danilo Krummrich <dakr@kernel.org>
To: Asahi Lina <lina@asahilina.net>
Cc: Dave Airlie <airlied@gmail.com>,
maarten.lankhorst@linux.intel.com, simona@ffwll.ch,
mripard@kernel.org, tzimmermann@suse.de, lyude@redhat.com,
acurrid@nvidia.com, daniel.almeida@collabora.com, j@jannau.net,
ojeda@kernel.org, alex.gaynor@gmail.com, boqun.feng@gmail.com,
gary@garyguo.net, bjorn3_gh@protonmail.com,
benno.lossin@proton.me, a.hindborg@kernel.org,
aliceryhl@google.com, tmgross@umich.edu,
rust-for-linux@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 0/8] DRM Rust abstractions
Date: Thu, 10 Apr 2025 12:23:46 +0200 [thread overview]
Message-ID: <Z_ecMl2QtAssfczJ@pollux> (raw)
In-Reply-To: <43ec8aba-f279-422d-95d1-68daac7eaed9@asahilina.net>
(Adding Sima and dri-devel back in.)
On Thu, Apr 10, 2025 at 04:12:13PM +0900, Asahi Lina wrote:
>
> P.S. my analysis based on the pasted code (since everyone here and
> everyone on Reddit is forcing me to do it) is that:
First of all, you keep talking as if I would have been resisting to do any
changes, even though I offered you to change things from the get-go.
Instead of taking the offer, you decided to go with wild accusations, without
even properly looking at things and understanding my intentions.
Given that you stepped back from kernel development, making clear that you don't
want to be bothered with it anymore (as you also repeated in this thread), I had
to take a decision: Do I "keep" your primary authorship for commits that I
(newly) create, commit messages I write and code that I substantially change, or
do I account for this by changing primary authorship while still giving you
credit.
The decision I took is clearly reasonable and *nothing* about it is uncommon.
I also want to point out that for patch "rust: drm: ioctl: Add DRM ioctl
abstraction" I kept your primary authorship, since I took the patch "as is" with
just very minor modifications.
However, I understand that you prefer to have primary authorship, even if the
code has been re-organized in new commits, moved, modified or rewritten.
This really is *totally* fine for me, and I won't argue about it (even though
one could).
> The series adds around 978 lines of code. After merging some code that
> was just moved around in the diff that Danilo posted, only 412 addition
> lines remain in the diff. So more than 50% of the raw remaining code is
> mine. If you exclude comments, Danilo only added 270 lines of actual
> code (and whitespace). And of those, a good portion were just minor
> changes and refactoring, not completely novel code (this also tracks
> with the stat that to get to those 270 lines, 379 were removed, and much
> of those probably pair up as minor refactorings and not outright novel
> code).
>
> In terms of actual code added an not just lines rearranged or further
> commented, I probably wrote at least 75% of this series. And I'm sure
> Danilo knows this, having done the refactoring/rearranging/modification
> work to get here.
I do not understand what you are trying to proof here and especially why.
I also do *not* agree with the above; to me it looks like it does not account
for the cases where code has been moved *and* modified.
Here's the full list of changes for the diff [1].
- rewrite of drm::Device
- full rewrite of the abstraction using the subclassing pattern
- rework of drm::Registration
- this may seem like a trivial simplification (or move), but has
architectural implications to prevent use-after-free bugs
- some members (vtable) of drm::Registration need to be tied to the
lifetime of the drm::Device instead, *not* the drm::Registration
- introduce Devres
- rework of drm::File
- switch to the Opaque<T> type
- fix (mutable) references to struct drm_file (which in this context is UB)
- restructure and rename functions to align with common kernel schemes
- rework of the GEM object abstractions
- switch to the Opaque<T> type
- fix (mutable) references to struct drm_gem_object (which in this context is UB)
- drop all custom reference types in favor of AlwaysRefCounted
- a bunch of minor changes and simplifications (e.g. IntoGEMObject trait)
- MISC
- write and fix lots of safety and invariant comments
- remove necessity for and convert 'as' casts
- bunch of other minor changes
The sum of the above is clearly *not* minor.
I really don't agree with the fact that you keep accusing me of "stealing" your
code, which I clearly did not. Trust me, I don't need that.
> Danilo: If you do not take me up on the CC-0 offer, I expect you to put
> my name as primary author of patches 3 through 7.
I offered this from the get-go, hence I will do so.
However, are you sure you really want primary authorship for "rust: drm: add
device abstraction", given that drm::Device is a full rewrite?
[1] https://pastebin.com/FT4tNn5d
next prev parent reply other threads:[~2025-04-10 10:23 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-25 23:54 [PATCH 0/8] DRM Rust abstractions Danilo Krummrich
2025-03-25 23:54 ` [PATCH 1/8] drm: drv: implement __drm_dev_alloc() Danilo Krummrich
2025-03-26 8:46 ` Maxime Ripard
2025-03-25 23:54 ` [PATCH 2/8] rust: drm: ioctl: Add DRM ioctl abstraction Danilo Krummrich
2025-03-25 23:54 ` [PATCH 3/8] rust: drm: add driver abstractions Danilo Krummrich
2025-03-26 9:05 ` Maxime Ripard
2025-03-28 22:00 ` Lyude Paul
2025-03-28 22:46 ` Danilo Krummrich
2025-03-25 23:54 ` [PATCH 4/8] rust: drm: add device abstraction Danilo Krummrich
2025-03-26 9:12 ` Maxime Ripard
2025-03-25 23:54 ` [PATCH 5/8] rust: drm: add DRM driver registration Danilo Krummrich
2025-03-26 9:24 ` Maxime Ripard
2025-03-26 10:46 ` Danilo Krummrich
2025-03-28 14:28 ` Maxime Ripard
2025-03-28 14:50 ` Danilo Krummrich
2025-04-10 9:23 ` Maxime Ripard
2025-03-25 23:54 ` [PATCH 6/8] rust: drm: file: Add File abstraction Danilo Krummrich
2025-03-28 14:42 ` Maxime Ripard
2025-03-25 23:54 ` [PATCH 7/8] rust: drm: gem: Add GEM object abstraction Danilo Krummrich
2025-03-25 23:54 ` [PATCH 8/8] MAINTAINERS: add DRM Rust source files to DRM DRIVERS Danilo Krummrich
2025-03-28 14:49 ` Maxime Ripard
2025-03-28 14:50 ` Danilo Krummrich
2025-04-08 16:29 ` [PATCH 0/8] DRM Rust abstractions Asahi Lina
2025-04-08 17:04 ` Danilo Krummrich
2025-04-08 18:06 ` Asahi Lina
2025-04-08 19:17 ` Danilo Krummrich
2025-04-09 7:49 ` Asahi Lina
2025-04-09 21:29 ` Dave Airlie
2025-04-10 4:33 ` Asahi Lina
2025-04-10 7:12 ` Asahi Lina
2025-04-10 10:23 ` Danilo Krummrich [this message]
2025-04-10 12:37 ` Asahi Lina
2025-04-10 13:33 ` Danilo Krummrich
2025-04-11 0:43 ` Dave Airlie
2025-04-11 6:53 ` Asahi Lina
2025-04-10 6:44 ` Simona Vetter
2025-04-10 8:14 ` Asahi Lina
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=Z_ecMl2QtAssfczJ@pollux \
--to=dakr@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=acurrid@nvidia.com \
--cc=airlied@gmail.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=daniel.almeida@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=j@jannau.net \
--cc=lina@asahilina.net \
--cc=lyude@redhat.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=tmgross@umich.edu \
--cc=tzimmermann@suse.de \
/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;
as well as URLs for NNTP newsgroup(s).