| Message ID | 20250325235522.3992-1-dakr@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | DRM Rust abstractions | expand |
On 3/26/25 8:54 AM, Danilo Krummrich wrote: > This is the series for the initial DRM Rust abstractions, including DRM device / > driver, IOCTL, File and GEM object abstractions. > > This series has been posted previously, however this is a long time ago and I > reworked a lot of things quite heavily. Hence, I decided to post this as a whole > new series. > > Besides the rework, I want to credit Lina for her initial work, which this > series is based on. > > In a private mail Lina told me to "feel free to take anything that's useful > from my past patch submissions or the downstream branches and use it/submit it > in any way". > > @Lina: If you, however, feel uncomfortable with any of the Co-developed-by: > tags, due to the major changes, please let me know. I'm wondering why you took over primary authorship for some patches. For example, patch #3 has you listed as primary author, and yet when I diff: git diff asahi-6.11-1 asahi-6.12.12-1 rust/kernel/drm/drv.rs | grep '^+' | wc -l 41 (Those two trees have my original commit and your commits, as rebased over by Janne). Of those 41 added lines, most are comments, and reworking Registration a bit. I thought general kernel etiquette is that you keep the original author unless you are literally rewriting the majority of the file from scratch... I'm really tired of kernel politics and I don't want to spend more brain cycles looking at all the other patches or having to argue (in fact I usually don't look at patch emails at all recently), but I would appreciate if you keep my authorship for files that I did largely author myself. After everything I've been going through the past weeks (some of the people on Cc know what that's about...) this feels like yet another slap in the face. > > Those changes include: > - switch to the subclassing pattern for DRM device > - rework of the GEM object abstraction; dropping the custom reference types in > favor of AlwaysRefCounted > - rework of the File abstractions > - rework of the driver registration > - lots of minor changes (e.g. to better align with existing abstractions) > > This patch series is also available in [1]; an example usage from nova-drm can > be found in [2] and [3]. > > [1] https://gitlab.freedesktop.org/drm/misc/kernel/-/tree/topic/rust-drm > [2] https://lore.kernel.org/nouveau/20250325232222.5326-1-dakr@kernel.org/ > [3] https://gitlab.freedesktop.org/drm/nova/-/tree/staging/nova-drm > > Asahi Lina (1): > rust: drm: ioctl: Add DRM ioctl abstraction > > Danilo Krummrich (7): > drm: drv: implement __drm_dev_alloc() > rust: drm: add driver abstractions > rust: drm: add device abstraction > rust: drm: add DRM driver registration > rust: drm: file: Add File abstraction > rust: drm: gem: Add GEM object abstraction > MAINTAINERS: add DRM Rust source files to DRM DRIVERS > > MAINTAINERS | 1 + > drivers/gpu/drm/drm_drv.c | 58 ++++-- > include/drm/drm_drv.h | 5 + > rust/bindings/bindings_helper.h | 6 + > rust/helpers/drm.c | 19 ++ > rust/helpers/helpers.c | 1 + > rust/kernel/drm/device.rs | 195 +++++++++++++++++++ > rust/kernel/drm/driver.rs | 194 +++++++++++++++++++ > rust/kernel/drm/file.rs | 99 ++++++++++ > rust/kernel/drm/gem/mod.rs | 321 ++++++++++++++++++++++++++++++++ > rust/kernel/drm/ioctl.rs | 159 ++++++++++++++++ > rust/kernel/drm/mod.rs | 19 ++ > rust/kernel/lib.rs | 2 + > rust/uapi/uapi_helper.h | 1 + > 14 files changed, 1064 insertions(+), 16 deletions(-) > create mode 100644 rust/helpers/drm.c > create mode 100644 rust/kernel/drm/device.rs > create mode 100644 rust/kernel/drm/driver.rs > create mode 100644 rust/kernel/drm/file.rs > create mode 100644 rust/kernel/drm/gem/mod.rs > create mode 100644 rust/kernel/drm/ioctl.rs > create mode 100644 rust/kernel/drm/mod.rs > ~~ Lina
On Wed, Apr 09, 2025 at 01:29:35AM +0900, Asahi Lina wrote: > On 3/26/25 8:54 AM, Danilo Krummrich wrote: > > This is the series for the initial DRM Rust abstractions, including DRM device / > > driver, IOCTL, File and GEM object abstractions. > > > > This series has been posted previously, however this is a long time ago and I > > reworked a lot of things quite heavily. Hence, I decided to post this as a whole > > new series. > > > > Besides the rework, I want to credit Lina for her initial work, which this > > series is based on. > > > > In a private mail Lina told me to "feel free to take anything that's useful > > from my past patch submissions or the downstream branches and use it/submit it > > in any way". > > > > @Lina: If you, however, feel uncomfortable with any of the Co-developed-by: > > tags, due to the major changes, please let me know. > > I'm wondering why you took over primary authorship for some patches. Because the patches did either not exist previously or have been changed extensively. For instance, the patch you are referring to below (commit 242ae06b5ec9 ("rust: drm: Add Device and Driver abstractions")) has been split up in three different patches, where one of them (patch #2) in this series has indeed mostly the same code, the other two (#3 and #4) were modified. > For > example, patch #3 has you listed as primary author, and yet when I diff: > > git diff asahi-6.11-1 asahi-6.12.12-1 rust/kernel/drm/drv.rs | grep '^+' > | wc -l > 41 > > (Those two trees have my original commit and your commits, as rebased > over by Janne). Not really, this series is much different than what is in asahi-6.12.12-1. > Of those 41 added lines, most are comments, and reworking Registration a > bit. > > I thought general kernel etiquette is that you keep the original author > unless you are literally rewriting the majority of the file from scratch... As mentioned above I re-organized patches and changed quite a lot of code. If, with this precondition, I would have kept you as "primary" author, you could have been complaining about me misrepresenting you / your work instead. Now, you could argue that I should have been asking first, right? But in a private mail you told me (and others that have been on CC as well) the following: "Please feel free to take anything that's useful from my past patch submissions or the downstream branches and use it/submit it in any way." You said "use it/submit it in any way". If you changed your mind on this, that is fine with me. Please let me know where you'd like to have primary authorship changed and how you'd like it to be. > I'm really tired of kernel politics and I don't want to spend more brain > cycles looking at all the other patches or having to argue (in fact I > usually don't look at patch emails at all recently), but I would > appreciate if you keep my authorship for files that I did largely author > myself. After everything I've been going through the past weeks (some of > the people on Cc know what that's about...) this feels like yet another > slap in the face. As mentioned, please diff the correct thing and then just tell me where you'd like to have primary authorship changed. > > > > Those changes include: > > - switch to the subclassing pattern for DRM device > > - rework of the GEM object abstraction; dropping the custom reference types in > > favor of AlwaysRefCounted > > - rework of the File abstractions > > - rework of the driver registration > > - lots of minor changes (e.g. to better align with existing abstractions) > > > > This patch series is also available in [1]; an example usage from nova-drm can > > be found in [2] and [3]. > > > > [1] https://gitlab.freedesktop.org/drm/misc/kernel/-/tree/topic/rust-drm > > [2] https://lore.kernel.org/nouveau/20250325232222.5326-1-dakr@kernel.org/ > > [3] https://gitlab.freedesktop.org/drm/nova/-/tree/staging/nova-drm > > > > Asahi Lina (1): > > rust: drm: ioctl: Add DRM ioctl abstraction > > > > Danilo Krummrich (7): > > drm: drv: implement __drm_dev_alloc() > > rust: drm: add driver abstractions > > rust: drm: add device abstraction > > rust: drm: add DRM driver registration > > rust: drm: file: Add File abstraction > > rust: drm: gem: Add GEM object abstraction > > MAINTAINERS: add DRM Rust source files to DRM DRIVERS > > > > MAINTAINERS | 1 + > > drivers/gpu/drm/drm_drv.c | 58 ++++-- > > include/drm/drm_drv.h | 5 + > > rust/bindings/bindings_helper.h | 6 + > > rust/helpers/drm.c | 19 ++ > > rust/helpers/helpers.c | 1 + > > rust/kernel/drm/device.rs | 195 +++++++++++++++++++ > > rust/kernel/drm/driver.rs | 194 +++++++++++++++++++ > > rust/kernel/drm/file.rs | 99 ++++++++++ > > rust/kernel/drm/gem/mod.rs | 321 ++++++++++++++++++++++++++++++++ > > rust/kernel/drm/ioctl.rs | 159 ++++++++++++++++ > > rust/kernel/drm/mod.rs | 19 ++ > > rust/kernel/lib.rs | 2 + > > rust/uapi/uapi_helper.h | 1 + > > 14 files changed, 1064 insertions(+), 16 deletions(-) > > create mode 100644 rust/helpers/drm.c > > create mode 100644 rust/kernel/drm/device.rs > > create mode 100644 rust/kernel/drm/driver.rs > > create mode 100644 rust/kernel/drm/file.rs > > create mode 100644 rust/kernel/drm/gem/mod.rs > > create mode 100644 rust/kernel/drm/ioctl.rs > > create mode 100644 rust/kernel/drm/mod.rs > > > > ~~ Lina >
On 4/9/25 2:04 AM, Danilo Krummrich wrote: > On Wed, Apr 09, 2025 at 01:29:35AM +0900, Asahi Lina wrote: >> On 3/26/25 8:54 AM, Danilo Krummrich wrote: >>> This is the series for the initial DRM Rust abstractions, including DRM device / >>> driver, IOCTL, File and GEM object abstractions. >>> >>> This series has been posted previously, however this is a long time ago and I >>> reworked a lot of things quite heavily. Hence, I decided to post this as a whole >>> new series. >>> >>> Besides the rework, I want to credit Lina for her initial work, which this >>> series is based on. >>> >>> In a private mail Lina told me to "feel free to take anything that's useful >>> from my past patch submissions or the downstream branches and use it/submit it >>> in any way". >>> >>> @Lina: If you, however, feel uncomfortable with any of the Co-developed-by: >>> tags, due to the major changes, please let me know. >> >> I'm wondering why you took over primary authorship for some patches. > > Because the patches did either not exist previously or have been changed > extensively. > > For instance, the patch you are referring to below (commit 242ae06b5ec9 ("rust: > drm: Add Device and Driver abstractions")) has been split up in three different > patches, where one of them (patch #2) in this series has indeed mostly the same > code, the other two (#3 and #4) were modified. > >> For >> example, patch #3 has you listed as primary author, and yet when I diff: >> >> git diff asahi-6.11-1 asahi-6.12.12-1 rust/kernel/drm/drv.rs | grep '^+' >> | wc -l >> 41 >> >> (Those two trees have my original commit and your commits, as rebased >> over by Janne). > > Not really, this series is much different than what is in asahi-6.12.12-1. > >> Of those 41 added lines, most are comments, and reworking Registration a >> bit. >> >> I thought general kernel etiquette is that you keep the original author >> unless you are literally rewriting the majority of the file from scratch... > > As mentioned above I re-organized patches and changed quite a lot of code. If, > with this precondition, I would have kept you as "primary" author, you could > have been complaining about me misrepresenting you / your work instead. > > Now, you could argue that I should have been asking first, right? > > But in a private mail you told me (and others that have been on CC as well) the > following: > > "Please feel free to take anything that's useful from my past patch > submissions or the downstream branches and use it/submit it in any way." > > You said "use it/submit it in any way". I thought keeping authorship is an implied part of kernel etiquette. Usually when you submit code someone else wrote, you keep them as primary author... I want you and others to use the code, that doesn't mean I want you to put your name on it as if you wrote most of it. > > If you changed your mind on this, that is fine with me. > > Please let me know where you'd like to have primary authorship changed and how > you'd like it to be. > >> I'm really tired of kernel politics and I don't want to spend more brain >> cycles looking at all the other patches or having to argue (in fact I >> usually don't look at patch emails at all recently), but I would >> appreciate if you keep my authorship for files that I did largely author >> myself. After everything I've been going through the past weeks (some of >> the people on Cc know what that's about...) this feels like yet another >> slap in the face. > > As mentioned, please diff the correct thing and then just tell me where you'd > like to have primary authorship changed. I don't even know what tree this series is supposed to apply onto (tried drm-misc next, torvalds/master, v6.15-rc1) so I'm just going to take drm-misc/topic/rust-drm and assume that's what this series includes. $ diff -urN rust/kernel/drm/drv.rs ../uplinux/rust/kernel/drm/driver.rs | grep '^+' | wc -l 45 So I'm diffing the correct thing now and the result is essentially identical. Meanwhile, device.rs has many additions... but a big chunk of those is code that was just moved from drv.rs (like drm_legacy_fields and the code that uses it). Again, I don't have the spoons to make some deep analysis here, you should know how much of the code you changed, added, or just moved around. I'm not going to litigate this further. If you think splitting up a commit into multiple commits and moving code around warrants taking over primary authorship of a project I've been working on for years now, so be it. I'm just disappointed. > >>> >>> Those changes include: >>> - switch to the subclassing pattern for DRM device >>> - rework of the GEM object abstraction; dropping the custom reference types in >>> favor of AlwaysRefCounted >>> - rework of the File abstractions >>> - rework of the driver registration >>> - lots of minor changes (e.g. to better align with existing abstractions) >>> >>> This patch series is also available in [1]; an example usage from nova-drm can >>> be found in [2] and [3]. >>> >>> [1] https://gitlab.freedesktop.org/drm/misc/kernel/-/tree/topic/rust-drm >>> [2] https://lore.kernel.org/nouveau/20250325232222.5326-1-dakr@kernel.org/ >>> [3] https://gitlab.freedesktop.org/drm/nova/-/tree/staging/nova-drm >>> >>> Asahi Lina (1): >>> rust: drm: ioctl: Add DRM ioctl abstraction >>> >>> Danilo Krummrich (7): >>> drm: drv: implement __drm_dev_alloc() >>> rust: drm: add driver abstractions >>> rust: drm: add device abstraction >>> rust: drm: add DRM driver registration >>> rust: drm: file: Add File abstraction >>> rust: drm: gem: Add GEM object abstraction >>> MAINTAINERS: add DRM Rust source files to DRM DRIVERS >>> >>> MAINTAINERS | 1 + >>> drivers/gpu/drm/drm_drv.c | 58 ++++-- >>> include/drm/drm_drv.h | 5 + >>> rust/bindings/bindings_helper.h | 6 + >>> rust/helpers/drm.c | 19 ++ >>> rust/helpers/helpers.c | 1 + >>> rust/kernel/drm/device.rs | 195 +++++++++++++++++++ >>> rust/kernel/drm/driver.rs | 194 +++++++++++++++++++ >>> rust/kernel/drm/file.rs | 99 ++++++++++ >>> rust/kernel/drm/gem/mod.rs | 321 ++++++++++++++++++++++++++++++++ >>> rust/kernel/drm/ioctl.rs | 159 ++++++++++++++++ >>> rust/kernel/drm/mod.rs | 19 ++ >>> rust/kernel/lib.rs | 2 + >>> rust/uapi/uapi_helper.h | 1 + >>> 14 files changed, 1064 insertions(+), 16 deletions(-) >>> create mode 100644 rust/helpers/drm.c >>> create mode 100644 rust/kernel/drm/device.rs >>> create mode 100644 rust/kernel/drm/driver.rs >>> create mode 100644 rust/kernel/drm/file.rs >>> create mode 100644 rust/kernel/drm/gem/mod.rs >>> create mode 100644 rust/kernel/drm/ioctl.rs >>> create mode 100644 rust/kernel/drm/mod.rs >>> >> >> ~~ Lina >> > ~~ Lina
On Wed, Apr 09, 2025 at 03:06:38AM +0900, Asahi Lina wrote: > On 4/9/25 2:04 AM, Danilo Krummrich wrote: > > On Wed, Apr 09, 2025 at 01:29:35AM +0900, Asahi Lina wrote: > >> On 3/26/25 8:54 AM, Danilo Krummrich wrote: > > > > You said "use it/submit it in any way". > > I thought keeping authorship is an implied part of kernel etiquette. > Usually when you submit code someone else wrote, you keep them as > primary author... I want you and others to use the code, that doesn't > mean I want you to put your name on it as if you wrote most of it. The broader context of the private mail was about you stepping back on kernel development. You did so with a few more details (which I'm not going to disclose), that made it clear to me that you don't want to be bothered with kernel development any more. In combination with you giving permission to "use it/submit it in any way", I thought it's better to just pick a safe path to not misrepresent you given all the changes I made. I do still credit you on all corresponding patches though. > >> I'm really tired of kernel politics and I don't want to spend more brain > >> cycles looking at all the other patches or having to argue (in fact I > >> usually don't look at patch emails at all recently), but I would > >> appreciate if you keep my authorship for files that I did largely author > >> myself. After everything I've been going through the past weeks (some of > >> the people on Cc know what that's about...) this feels like yet another > >> slap in the face. > > > > As mentioned, please diff the correct thing and then just tell me where you'd > > like to have primary authorship changed. > > I don't even know what tree this series is supposed to apply onto (tried > drm-misc next, torvalds/master, v6.15-rc1) so I'm just going to take > drm-misc/topic/rust-drm and assume that's what this series includes. > > $ diff -urN rust/kernel/drm/drv.rs ../uplinux/rust/kernel/drm/driver.rs > | grep '^+' | wc -l > 45 > > So I'm diffing the correct thing now and the result is essentially > identical. > > Meanwhile, device.rs has many additions... but a big chunk of those is > code that was just moved from drv.rs (like drm_legacy_fields and the > code that uses it). Except drm_legacy_fields! and VTABLE (which is just trival boilerplate code) device.rs changed fundamentally, i.e. I switched the device abstraction to use the subclassing pattern. If you look further you will find that I really changed a lot of things. I have *nothing* to hide, here's the overall diff for all the changes I made: [1] https://pastebin.com/FT4tNn5d > > Again, I don't have the spoons to make some deep analysis here, you > should know how much of the code you changed, added, or just moved > around. I'm not going to litigate this further. If you think splitting > up a commit into multiple commits and moving code around warrants taking > over primary authorship of a project I've been working on for years now, > so be it. You just said you "don't have the spoons to make some deep analysis here" and right below you acuse me of just "moving code around". Which means that you do so *without* evidence. And again, I have *nothing* to hide, see [1]. Besides that I also told you that I'm fine to change primary authership, if you tell me where you think it would be appropriate (even though I do think my changes do justify how things are currently). > I'm just disappointed. That's where you are maneuvering *yourself* into. You could have easily just asked me to change things for patch #X, #Y and #Z. Instead you outright started with accusing me of things. I also feel like you intentionally try to misrepresent what I am doing and what my intentions are. I neither have the time, nor am I willing to deal with random drama like this. If you want something changed, just go ahead and tell me what, *without* more drama and without more accusing me of things.
On 4/9/25 4:17 AM, Danilo Krummrich wrote: > On Wed, Apr 09, 2025 at 03:06:38AM +0900, Asahi Lina wrote: >> On 4/9/25 2:04 AM, Danilo Krummrich wrote: >>> On Wed, Apr 09, 2025 at 01:29:35AM +0900, Asahi Lina wrote: >>>> On 3/26/25 8:54 AM, Danilo Krummrich wrote: >>> >>> You said "use it/submit it in any way". >> >> I thought keeping authorship is an implied part of kernel etiquette. >> Usually when you submit code someone else wrote, you keep them as >> primary author... I want you and others to use the code, that doesn't >> mean I want you to put your name on it as if you wrote most of it. > > The broader context of the private mail was about you stepping back on kernel > development. You did so with a few more details (which I'm not going to > disclose), that made it clear to me that you don't want to be bothered with > kernel development any more. > > In combination with you giving permission to "use it/submit it in any way", I > thought it's better to just pick a safe path to not misrepresent you given all > the changes I made. > > I do still credit you on all corresponding patches though. > >>>> I'm really tired of kernel politics and I don't want to spend more brain >>>> cycles looking at all the other patches or having to argue (in fact I >>>> usually don't look at patch emails at all recently), but I would >>>> appreciate if you keep my authorship for files that I did largely author >>>> myself. After everything I've been going through the past weeks (some of >>>> the people on Cc know what that's about...) this feels like yet another >>>> slap in the face. >>> >>> As mentioned, please diff the correct thing and then just tell me where you'd >>> like to have primary authorship changed. >> >> I don't even know what tree this series is supposed to apply onto (tried >> drm-misc next, torvalds/master, v6.15-rc1) so I'm just going to take >> drm-misc/topic/rust-drm and assume that's what this series includes. >> >> $ diff -urN rust/kernel/drm/drv.rs ../uplinux/rust/kernel/drm/driver.rs >> | grep '^+' | wc -l >> 45 >> >> So I'm diffing the correct thing now and the result is essentially >> identical. >> >> Meanwhile, device.rs has many additions... but a big chunk of those is >> code that was just moved from drv.rs (like drm_legacy_fields and the >> code that uses it). > > Except drm_legacy_fields! and VTABLE (which is just trival boilerplate code) > device.rs changed fundamentally, i.e. I switched the device abstraction to use > the subclassing pattern. > > If you look further you will find that I really changed a lot of things. > > I have *nothing* to hide, here's the overall diff for all the changes I made: > > [1] https://pastebin.com/FT4tNn5d > >> >> Again, I don't have the spoons to make some deep analysis here, you >> should know how much of the code you changed, added, or just moved >> around. I'm not going to litigate this further. If you think splitting >> up a commit into multiple commits and moving code around warrants taking >> over primary authorship of a project I've been working on for years now, >> so be it. > > You just said you "don't have the spoons to make some deep analysis here" and > right below you acuse me of just "moving code around". > > Which means that you do so *without* evidence. And again, I have *nothing* to > hide, see [1]. > > Besides that I also told you that I'm fine to change primary authership, if you > tell me where you think it would be appropriate (even though I do think my > changes do justify how things are currently). > >> I'm just disappointed. > > That's where you are maneuvering *yourself* into. > > You could have easily just asked me to change things for patch #X, #Y and #Z. > > Instead you outright started with accusing me of things. I also feel like you > intentionally try to misrepresent what I am doing and what my intentions are. > > I neither have the time, nor am I willing to deal with random drama like this. > > If you want something changed, just go ahead and tell me what, *without* more > drama and without more accusing me of things. > Alright, then please remove my authorship entirely from this series, including Co-developed-by and signoff lines. I hereby release my code as CC-0, which means you don't need the signoffs, it's yours now. The same applies to any future code submitted that I originally authored as part of the Asahi kernel git tree. That way we don't need to argue about any of this. I thought asking for patches that I mostly authored to keep my Git authorship would be an uncontroversial request (and not unreasonable to ask you to figure out which those are, since you made the changes/splits, and #3 clearly is one), but apparently even that gets you flamed on Linux threads these days. I regret having been part of this community. ~~ Lina
On Wed, 9 Apr 2025 at 17:49, Asahi Lina <lina@asahilina.net> wrote: > > > > On 4/9/25 4:17 AM, Danilo Krummrich wrote: > > On Wed, Apr 09, 2025 at 03:06:38AM +0900, Asahi Lina wrote: > >> On 4/9/25 2:04 AM, Danilo Krummrich wrote: > >>> On Wed, Apr 09, 2025 at 01:29:35AM +0900, Asahi Lina wrote: > >>>> On 3/26/25 8:54 AM, Danilo Krummrich wrote: > >>> > >>> You said "use it/submit it in any way". > >> > >> I thought keeping authorship is an implied part of kernel etiquette. > >> Usually when you submit code someone else wrote, you keep them as > >> primary author... I want you and others to use the code, that doesn't > >> mean I want you to put your name on it as if you wrote most of it. > > > > The broader context of the private mail was about you stepping back on kernel > > development. You did so with a few more details (which I'm not going to > > disclose), that made it clear to me that you don't want to be bothered with > > kernel development any more. > > > > In combination with you giving permission to "use it/submit it in any way", I > > thought it's better to just pick a safe path to not misrepresent you given all > > the changes I made. > > > > I do still credit you on all corresponding patches though. > > > >>>> I'm really tired of kernel politics and I don't want to spend more brain > >>>> cycles looking at all the other patches or having to argue (in fact I > >>>> usually don't look at patch emails at all recently), but I would > >>>> appreciate if you keep my authorship for files that I did largely author > >>>> myself. After everything I've been going through the past weeks (some of > >>>> the people on Cc know what that's about...) this feels like yet another > >>>> slap in the face. > >>> > >>> As mentioned, please diff the correct thing and then just tell me where you'd > >>> like to have primary authorship changed. > >> > >> I don't even know what tree this series is supposed to apply onto (tried > >> drm-misc next, torvalds/master, v6.15-rc1) so I'm just going to take > >> drm-misc/topic/rust-drm and assume that's what this series includes. > >> > >> $ diff -urN rust/kernel/drm/drv.rs ../uplinux/rust/kernel/drm/driver.rs > >> | grep '^+' | wc -l > >> 45 > >> > >> So I'm diffing the correct thing now and the result is essentially > >> identical. > >> > >> Meanwhile, device.rs has many additions... but a big chunk of those is > >> code that was just moved from drv.rs (like drm_legacy_fields and the > >> code that uses it). > > > > Except drm_legacy_fields! and VTABLE (which is just trival boilerplate code) > > device.rs changed fundamentally, i.e. I switched the device abstraction to use > > the subclassing pattern. > > > > If you look further you will find that I really changed a lot of things. > > > > I have *nothing* to hide, here's the overall diff for all the changes I made: > > > > [1] https://pastebin.com/FT4tNn5d > > > >> > >> Again, I don't have the spoons to make some deep analysis here, you > >> should know how much of the code you changed, added, or just moved > >> around. I'm not going to litigate this further. If you think splitting > >> up a commit into multiple commits and moving code around warrants taking > >> over primary authorship of a project I've been working on for years now, > >> so be it. > > > > You just said you "don't have the spoons to make some deep analysis here" and > > right below you acuse me of just "moving code around". > > > > Which means that you do so *without* evidence. And again, I have *nothing* to > > hide, see [1]. > > > > Besides that I also told you that I'm fine to change primary authership, if you > > tell me where you think it would be appropriate (even though I do think my > > changes do justify how things are currently). > > > >> I'm just disappointed. > > > > That's where you are maneuvering *yourself* into. > > > > You could have easily just asked me to change things for patch #X, #Y and #Z. > > > > Instead you outright started with accusing me of things. I also feel like you > > intentionally try to misrepresent what I am doing and what my intentions are. > > > > I neither have the time, nor am I willing to deal with random drama like this. > > > > If you want something changed, just go ahead and tell me what, *without* more > > drama and without more accusing me of things. > > > > Alright, then please remove my authorship entirely from this series, > including Co-developed-by and signoff lines. I hereby release my code as > CC-0, which means you don't need the signoffs, it's yours now. The same > applies to any future code submitted that I originally authored as part > of the Asahi kernel git tree. That way we don't need to argue about any > of this. > > I thought asking for patches that I mostly authored to keep my Git > authorship would be an uncontroversial request (and not unreasonable to > ask you to figure out which those are, since you made the > changes/splits, and #3 clearly is one), but apparently even that gets > you flamed on Linux threads these days. > > I regret having been part of this community. Look, this isn't Crank or Speed, there is no need to keep the drama level above 50 to sort this out. This also isn't exactly how best to relicense code, so I think we should abstain from doing anything to help promote more drama. The project will maintain authorship/signoffs on any patches that are clearly still authored by you, we will err on the side of caution and on rewritten patches which share some decent amount of history shall retain your authorship. In this case it does appear instead of putting in the 5 minutes of looking at Danilo's reasoning and supplied diff, and either saying "my bad, this is sufficiently new code and I don't feel I wrote it" or "I'd still prefer to retain authorship despite your changes", both of which Danilo indicated would be respected you somehow picked door number 3 which probably took more time and effort than either of the above options. Again no need to pick door number 3 here, you can let the bus go below 50, it won't explode. Dave.
On Thu, Apr 10, 2025 at 07:29:30AM +1000, Dave Airlie wrote: > On Wed, 9 Apr 2025 at 17:49, Asahi Lina <lina@asahilina.net> wrote: > > > > > > > > On 4/9/25 4:17 AM, Danilo Krummrich wrote: > > > On Wed, Apr 09, 2025 at 03:06:38AM +0900, Asahi Lina wrote: > > >> On 4/9/25 2:04 AM, Danilo Krummrich wrote: > > >>> On Wed, Apr 09, 2025 at 01:29:35AM +0900, Asahi Lina wrote: > > >>>> On 3/26/25 8:54 AM, Danilo Krummrich wrote: > > >>> > > >>> You said "use it/submit it in any way". > > >> > > >> I thought keeping authorship is an implied part of kernel etiquette. > > >> Usually when you submit code someone else wrote, you keep them as > > >> primary author... I want you and others to use the code, that doesn't > > >> mean I want you to put your name on it as if you wrote most of it. > > > > > > The broader context of the private mail was about you stepping back on kernel > > > development. You did so with a few more details (which I'm not going to > > > disclose), that made it clear to me that you don't want to be bothered with > > > kernel development any more. > > > > > > In combination with you giving permission to "use it/submit it in any way", I > > > thought it's better to just pick a safe path to not misrepresent you given all > > > the changes I made. > > > > > > I do still credit you on all corresponding patches though. > > > > > >>>> I'm really tired of kernel politics and I don't want to spend more brain > > >>>> cycles looking at all the other patches or having to argue (in fact I > > >>>> usually don't look at patch emails at all recently), but I would > > >>>> appreciate if you keep my authorship for files that I did largely author > > >>>> myself. After everything I've been going through the past weeks (some of > > >>>> the people on Cc know what that's about...) this feels like yet another > > >>>> slap in the face. > > >>> > > >>> As mentioned, please diff the correct thing and then just tell me where you'd > > >>> like to have primary authorship changed. > > >> > > >> I don't even know what tree this series is supposed to apply onto (tried > > >> drm-misc next, torvalds/master, v6.15-rc1) so I'm just going to take > > >> drm-misc/topic/rust-drm and assume that's what this series includes. > > >> > > >> $ diff -urN rust/kernel/drm/drv.rs ../uplinux/rust/kernel/drm/driver.rs > > >> | grep '^+' | wc -l > > >> 45 > > >> > > >> So I'm diffing the correct thing now and the result is essentially > > >> identical. > > >> > > >> Meanwhile, device.rs has many additions... but a big chunk of those is > > >> code that was just moved from drv.rs (like drm_legacy_fields and the > > >> code that uses it). > > > > > > Except drm_legacy_fields! and VTABLE (which is just trival boilerplate code) > > > device.rs changed fundamentally, i.e. I switched the device abstraction to use > > > the subclassing pattern. > > > > > > If you look further you will find that I really changed a lot of things. > > > > > > I have *nothing* to hide, here's the overall diff for all the changes I made: > > > > > > [1] https://pastebin.com/FT4tNn5d > > > > > >> > > >> Again, I don't have the spoons to make some deep analysis here, you > > >> should know how much of the code you changed, added, or just moved > > >> around. I'm not going to litigate this further. If you think splitting > > >> up a commit into multiple commits and moving code around warrants taking > > >> over primary authorship of a project I've been working on for years now, > > >> so be it. > > > > > > You just said you "don't have the spoons to make some deep analysis here" and > > > right below you acuse me of just "moving code around". > > > > > > Which means that you do so *without* evidence. And again, I have *nothing* to > > > hide, see [1]. > > > > > > Besides that I also told you that I'm fine to change primary authership, if you > > > tell me where you think it would be appropriate (even though I do think my > > > changes do justify how things are currently). > > > > > >> I'm just disappointed. > > > > > > That's where you are maneuvering *yourself* into. > > > > > > You could have easily just asked me to change things for patch #X, #Y and #Z. > > > > > > Instead you outright started with accusing me of things. I also feel like you > > > intentionally try to misrepresent what I am doing and what my intentions are. > > > > > > I neither have the time, nor am I willing to deal with random drama like this. > > > > > > If you want something changed, just go ahead and tell me what, *without* more > > > drama and without more accusing me of things. > > > > > > > Alright, then please remove my authorship entirely from this series, > > including Co-developed-by and signoff lines. I hereby release my code as > > CC-0, which means you don't need the signoffs, it's yours now. The same > > applies to any future code submitted that I originally authored as part > > of the Asahi kernel git tree. That way we don't need to argue about any > > of this. > > > > I thought asking for patches that I mostly authored to keep my Git > > authorship would be an uncontroversial request (and not unreasonable to > > ask you to figure out which those are, since you made the > > changes/splits, and #3 clearly is one), but apparently even that gets > > you flamed on Linux threads these days. > > > > I regret having been part of this community. > > Look, this isn't Crank or Speed, there is no need to keep the drama > level above 50 to sort this out. > > This also isn't exactly how best to relicense code, so I think we > should abstain from doing anything to help promote more drama. > > The project will maintain authorship/signoffs on any patches that are > clearly still authored by you, we will err on the side of caution and > on rewritten patches which share some decent amount of history shall > retain your authorship. In this case it does appear instead of putting > in the 5 minutes of looking at Danilo's reasoning and supplied diff, > and either saying "my bad, this is sufficiently new code and I don't > feel I wrote it" or "I'd still prefer to retain authorship despite > your changes", both of which Danilo indicated would be respected you > somehow picked door number 3 which probably took more time and effort > than either of the above options. Again no need to pick door number 3 > here, you can let the bus go below 50, it won't explode. To emphasis and maybe a bit more dry&serious, signed off by lines are not optional, because they signify agreement to the developer certificate of origin irrespective of the original license. Upstream has some patches without sob lines from all authors (well copyright holders to be strict, with companies there's often some internal authors that get dropped), but that is some very special case and needs real care. On the topic itself there's a few different ways to do this, depending whether it's more co-authorship, a complete rewrite or just some small bugfixes on top of an existing patch. The important part is that all authors are acknowledged, and that we have sob lines from everyone. Ideally also with archive links, where that's not obvious, e.g. when patch titles changed or the entire series was rewritten or when the original patch never was submitted to a list tracked by lore.k.o. Unfortunately git doesn't allow multiple authors, so we cannot acknowledge them all exactly equally due to lacking tooling in the co-authored case. But that's what the Co-Authored-by or similar tags are meant for. Cheers, Sima
On 3/26/25 8:54 AM, Danilo Krummrich wrote: > This is the series for the initial DRM Rust abstractions, including DRM device / > driver, IOCTL, File and GEM object abstractions. > > This series has been posted previously, however this is a long time ago and I > reworked a lot of things quite heavily. Hence, I decided to post this as a whole > new series. > > Besides the rework, I want to credit Lina for her initial work, which this > series is based on. > > In a private mail Lina told me to "feel free to take anything that's useful > from my past patch submissions or the downstream branches and use it/submit it > in any way". > > @Lina: If you, however, feel uncomfortable with any of the Co-developed-by: > tags, due to the major changes, please let me know. It was brought to my attention that this sentence could be interpreted in more than one way. To me, it reads as: If you, however, feel uncomfortable [am bothered by their presence] with any of the Co-developed-by: tags [which credit me], due to the major changes [as in, the major changes make me uncomfortable with the tags, because it's no longer all/mostly my code], please let me know [so I can remove them and therefore not credit you as author at all]. A single change, removing a comma, turns it into: If you, however, feel uncomfortable with any of the Co-developed-by: tags [am bothered by the situation of being listed only as Co-developed-by] due to the major changes [which was done that way due to the major changes], please let me know [so I can change authorship to you]. If you intended the latter interpretation, then I think this is one of those cases where unclear communication leads the conversation and the tone well off the rails. If I had perceived that you were open to promoting me to primary author, as opposed to open to demoting me to zero credit, I would have been a lot less upset about the situation. (If you did intend my original interpretation though, then quite frankly, WTF.) > > Those changes include: > - switch to the subclassing pattern for DRM device > - rework of the GEM object abstraction; dropping the custom reference types in > favor of AlwaysRefCounted > - rework of the File abstractions > - rework of the driver registration > - lots of minor changes (e.g. to better align with existing abstractions) > > This patch series is also available in [1]; an example usage from nova-drm can > be found in [2] and [3]. > > [1] https://gitlab.freedesktop.org/drm/misc/kernel/-/tree/topic/rust-drm > [2] https://lore.kernel.org/nouveau/20250325232222.5326-1-dakr@kernel.org/ > [3] https://gitlab.freedesktop.org/drm/nova/-/tree/staging/nova-drm > > Asahi Lina (1): > rust: drm: ioctl: Add DRM ioctl abstraction > > Danilo Krummrich (7): > drm: drv: implement __drm_dev_alloc() > rust: drm: add driver abstractions > rust: drm: add device abstraction > rust: drm: add DRM driver registration > rust: drm: file: Add File abstraction > rust: drm: gem: Add GEM object abstraction > MAINTAINERS: add DRM Rust source files to DRM DRIVERS > > MAINTAINERS | 1 + > drivers/gpu/drm/drm_drv.c | 58 ++++-- > include/drm/drm_drv.h | 5 + > rust/bindings/bindings_helper.h | 6 + > rust/helpers/drm.c | 19 ++ > rust/helpers/helpers.c | 1 + > rust/kernel/drm/device.rs | 195 +++++++++++++++++++ > rust/kernel/drm/driver.rs | 194 +++++++++++++++++++ > rust/kernel/drm/file.rs | 99 ++++++++++ > rust/kernel/drm/gem/mod.rs | 321 ++++++++++++++++++++++++++++++++ > rust/kernel/drm/ioctl.rs | 159 ++++++++++++++++ > rust/kernel/drm/mod.rs | 19 ++ > rust/kernel/lib.rs | 2 + > rust/uapi/uapi_helper.h | 1 + > 14 files changed, 1064 insertions(+), 16 deletions(-) > create mode 100644 rust/helpers/drm.c > create mode 100644 rust/kernel/drm/device.rs > create mode 100644 rust/kernel/drm/driver.rs > create mode 100644 rust/kernel/drm/file.rs > create mode 100644 rust/kernel/drm/gem/mod.rs > create mode 100644 rust/kernel/drm/ioctl.rs > create mode 100644 rust/kernel/drm/mod.rs > ~~ Lina
(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
On 4/10/25 7:23 PM, Danilo Krummrich wrote: > (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. Repeatedly offering trivialities as counterarguments, such as that my initial analysis was incorrect (when it wasn't), or that an offhand comment I made in my second analysis was more limited in scope than you expected, *is* resisting. Even if you say "you will do X", if you keep bringing up reasons why my motivation to do X is flawed, that *is* resisting, in thinly veiled form. Not resisting would've been to say "sorry, which patches would you like to retain ownership for? I think X, Y make sense, while Z is mostly new code." > Instead of taking the offer, you decided to go with wild accusations, without > even properly looking at things and understanding my intentions. I never accused you of anything beyond taking over primary authorship of the patches, which is something you did, in fact, do. > 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. Just because I stepped back doesn't mean you can't send me an email to ask a question to make sure you get upstreaming my code respecting my wishes for attribution. Though given the mess this turned into, as soon as this conversation is over, I will be sending all kernel-related emails directly to sieve-discard. While a simple question would have been fine and encouraged, this mess is not, and I do not have the time or mental health cycles to deal with any more of this going forward. So indeed, if you ever find yourself questioning something about my code *going forward*, please take your best guess, because I'm now really done with kernel involvement, completely. > > The decision I took is clearly reasonable and *nothing* about it is uncommon. As far as I am concerned, reorganizing someone's code and commits and doing so as your own commit identity *without* having previously agreed to do things that way (and without knowing that person well enough to know it will be acceptable) is not common, and should not be common in any respectful, well-functioning community, and is not something I've ever done myself. Those are things you do with prior, informed consent between both parties. Without explicit consent, you keep the authorship info. > 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. I'm aware. > 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. Correct. > This really is *totally* fine for me, and I won't argue about it (even though > one could). Continuing to mention that "one could" and previously "even though I do think my changes do justify how things are currently" means no, you are not totally fine with it, and you are in fact arguing about it. Just because you ostensibly intend to let me win the argument does not mean you aren't arguing about it, because you are. > >> 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'm trying to give a rough statistic of how much of the code is mine vs. yours, because apparently you (and others in the giant Reddit thread this somehow spawned) expect me to actually analyze the code to determine what the authorship should be. This could have ben avoided had you just *told* me "yeah, I think you should be the owner of most of the patches except maybe drm::Device, can you take a look at that one and see if that makes sense?" instead of sending me off to decide which patches I should own, as if I need to come up with my own analysis and conclusions while you already know what changes were made and to what code. > 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. Of course it does. I only deleted a small section of code from the diff that was moved verbatim and not modified. Plenty of code was moved and modified, and that's all accounted to you. > > 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. And yet it clearly does not amount to a complete rewrite of the entirety or most of the code, never mind the engineering and design that went into the abstractions in the first place, which is not something you can even measure in terms of lines of code. I'm quite certain I spent more hours hacking on this code than you did (and in fact, most of my time is documented in public YouTube videos), especially considering I put it into production with a real driver. > 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. I'm getting really tired of *your* false accusations. I never accused you of "stealing" code, I only ever talked about primary authorship. If you are interpreting that as "stealing" that is something you are maneuvering *yourself* into, to use your own words. >> 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 > The vtable/legacy stuff came straight from the other file. The "rewrite" is, quite frankly, an obvious refactor (the original code was written before the PinInit stuff even existed so it could not have been done that way, and I've done this same refactor for other bits of code many times before and would never call that a rewrite), but given there's 30-odd lines of new code (with comments) in the Device<T>::new() method that comprises most of the actual effort, and most of the rest of the file is boilerplate... sure, you can put yourself as primary author for that one if you wish. See? You could have started with that story about drm::Device being a more major change than the others and spared us all the blind arguing and wasting of time. ~~ Lina
I'm only gonna reply on the things that may be relevant for other people too. I don't really care about anything else. On Thu, Apr 10, 2025 at 09:37:39PM +0900, Asahi Lina wrote: > On 4/10/25 7:23 PM, Danilo Krummrich wrote: > > Just because I stepped back doesn't mean you can't send me an email to > ask a question to make sure you get upstreaming my code respecting my > wishes for attribution. You send out a mail to me and other people, that you'll step back from kernel development and additionally told people: "Please feel free to take anything that's useful from my past patch submissions or the downstream branches and use it/submit it in any way." But then... > > 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. > > Correct. ...you say this. To me this is contradictive, but I think we can agree that it is at least ambiguous. I suggest you to reply to your original mail and clarify this for other people as well. Otherwise you may see yourself in the same situation again, sooner or later. Also because this is uncommon, no one expects that. Ususally - and that includes me as well - people are much more worried to be misrepresented as the author of stuff that has changed too much from their original code. > > This really is *totally* fine for me, and I won't argue about it (even though > > one could). > > Continuing to mention that "one could" and previously "even though I do > think my changes do justify how things are currently" means no, you are > not totally fine with it, and you are in fact arguing about it. No, I can be totally fine to comply with your request and still be convinced that what I went with was reasonable. I even had to point this out, since otherwise it can be read as if I would not be convinced that I did the correct and reasonable thing.
> > > 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. > > Correct. For anyone working in this area that is intending to upstream anything from asahi, I think if code is rewritten completely it's probably not consistent to keep the primary author. Copyright doesn't cover ideas, it covers the code. It's fine to add acknowledgements and other tags. For all the other cases where it's just moving code around or modifying it, please try and retain the primary author. I'd suggest if anyone is basing stuff on the Asahi tree, they try to take things as-is as closely as possible, then use subsequent commits to clean/fix/rework, this might mean we have to live with some messy history that isn't easily bisectable, but I think to avoid any confusion later and to keep from repeatedly bothering Lina with kernel development questions on what is acceptable for what patches, we should try to remain consistent here. If you write new code from scratch without reference to the asahi tree at all, please try and state this is a clean implementation to avoid future possible confusions, if you are aware there is asahi code, though I realise that could be contradictory. There are often cases where there is only one way to write some code and I'd rather we don't fall into unwarranted accusations of bad behaviour. Dave.
On 4/11/25 9:43 AM, Dave Airlie wrote: >> >>> 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. >> >> Correct. > > For anyone working in this area that is intending to upstream anything > from asahi, I think if code is rewritten completely it's probably not > consistent to keep the primary author. Copyright doesn't cover ideas, > it covers the code. I think you're conflating two unrelated things here. Copyright has nothing to do with who is the primary Git author. As far as copyright is concerned, Danilo could submit everything as-is. Since I'm still mentioned as co-developer, there is no copyright issue. The primary author story is about FOSS etiquette, not a legal argument. If you "rewrite" (as in not directly copying and pasting the original) code while closely referencing the original and retaining some/much of the substance, that is still covered by copyright. This is why the clean-room process exists for reverse engineering, and why the Asahi project has rules that it does not accept code from people who have exposed themselves to Apple code or disassembly in most cases, and why both Asahi and Nouveau rely on black-box register and memory tracing for reverse engineering GPUs. If you rewrite code from scratch without referencing the original at all and without retaining any of the substance of the original, then of course, that is not a derivative work, and the author of the original would not have to be mentioned as author at all. This is how projects like Wine reimplement the Windows API. In this case, Danilo "rewrote" (I would say refactored) the Device abstraction. We can decide who gets to be primary author, but I don't think any lawyer would advise him to completely remove my attribution entirely, implying there is nothing left copyright by me. ~~ Lina
This is the series for the initial DRM Rust abstractions, including DRM device / driver, IOCTL, File and GEM object abstractions. This series has been posted previously, however this is a long time ago and I reworked a lot of things quite heavily. Hence, I decided to post this as a whole new series. Besides the rework, I want to credit Lina for her initial work, which this series is based on. In a private mail Lina told me to "feel free to take anything that's useful from my past patch submissions or the downstream branches and use it/submit it in any way". @Lina: If you, however, feel uncomfortable with any of the Co-developed-by: tags, due to the major changes, please let me know. Those changes include: - switch to the subclassing pattern for DRM device - rework of the GEM object abstraction; dropping the custom reference types in favor of AlwaysRefCounted - rework of the File abstractions - rework of the driver registration - lots of minor changes (e.g. to better align with existing abstractions) This patch series is also available in [1]; an example usage from nova-drm can be found in [2] and [3]. [1] https://gitlab.freedesktop.org/drm/misc/kernel/-/tree/topic/rust-drm [2] https://lore.kernel.org/nouveau/20250325232222.5326-1-dakr@kernel.org/ [3] https://gitlab.freedesktop.org/drm/nova/-/tree/staging/nova-drm Asahi Lina (1): rust: drm: ioctl: Add DRM ioctl abstraction Danilo Krummrich (7): drm: drv: implement __drm_dev_alloc() rust: drm: add driver abstractions rust: drm: add device abstraction rust: drm: add DRM driver registration rust: drm: file: Add File abstraction rust: drm: gem: Add GEM object abstraction MAINTAINERS: add DRM Rust source files to DRM DRIVERS MAINTAINERS | 1 + drivers/gpu/drm/drm_drv.c | 58 ++++-- include/drm/drm_drv.h | 5 + rust/bindings/bindings_helper.h | 6 + rust/helpers/drm.c | 19 ++ rust/helpers/helpers.c | 1 + rust/kernel/drm/device.rs | 195 +++++++++++++++++++ rust/kernel/drm/driver.rs | 194 +++++++++++++++++++ rust/kernel/drm/file.rs | 99 ++++++++++ rust/kernel/drm/gem/mod.rs | 321 ++++++++++++++++++++++++++++++++ rust/kernel/drm/ioctl.rs | 159 ++++++++++++++++ rust/kernel/drm/mod.rs | 19 ++ rust/kernel/lib.rs | 2 + rust/uapi/uapi_helper.h | 1 + 14 files changed, 1064 insertions(+), 16 deletions(-) create mode 100644 rust/helpers/drm.c create mode 100644 rust/kernel/drm/device.rs create mode 100644 rust/kernel/drm/driver.rs create mode 100644 rust/kernel/drm/file.rs create mode 100644 rust/kernel/drm/gem/mod.rs create mode 100644 rust/kernel/drm/ioctl.rs create mode 100644 rust/kernel/drm/mod.rs