Conor Dooley
Posts
505Following
144Followers
173I like cycling, powerlifting, bad video games and metal.
Otherwise, I occupy my time with various bits in RISC-V land.
~useless, placeholder, website: https://www.conchuod.ie/
@marcan @ljs
Airing grievances about maintainers aside, somewhere to check per-subsystem "quirks" would actually be helpful.
You've been around longer than I have, so I suppose you're aware of https://docs.kernel.org/process/maintainer-handbooks.html
although unfortunately that only covers two subsystems!
I guess in RISC-V land we also have https://docs.kernel.org/riscv/patch-acceptance.html that defines some constraints on submissions.
Creating a maintainer-handbook on someone's behalf seems a bit hostile, but perhaps having a list with "quirks" would encourage people to either drop or properly document them...
There's subsystems where the maintainer doesn't reply to patches, there's no git etc tree & the only way to know if something has been applied is when it shows up in -rc1!
If that confuses consistent contributors, documenting it for something like prolific like your apple-silicon stuff that, I assume, attracts new contributors seems helpful.
Airing grievances about maintainers aside, somewhere to check per-subsystem "quirks" would actually be helpful.
You've been around longer than I have, so I suppose you're aware of https://docs.kernel.org/process/maintainer-handbooks.html
although unfortunately that only covers two subsystems!
I guess in RISC-V land we also have https://docs.kernel.org/riscv/patch-acceptance.html that defines some constraints on submissions.
Creating a maintainer-handbook on someone's behalf seems a bit hostile, but perhaps having a list with "quirks" would encourage people to either drop or properly document them...
There's subsystems where the maintainer doesn't reply to patches, there's no git etc tree & the only way to know if something has been applied is when it shows up in -rc1!
If that confuses consistent contributors, documenting it for something like prolific like your apple-silicon stuff that, I assume, attracts new contributors seems helpful.
1
0
2
Conor Dooley
conor
I guess since there is no quote retweet here,
https://social.kernel.org/notice/ARLXuuUYGeIWtYMHbs
>every new contributor has to build that list from scratch and suffer until they figured it out.
Whenever I write something critical I think of one of the reviews I received early on, for something that was admittedly sub-par, and hope not to come across the way that email did.
https://social.kernel.org/notice/ARLXuuUYGeIWtYMHbs
>every new contributor has to build that list from scratch and suffer until they figured it out.
Whenever I write something critical I think of one of the reviews I received early on, for something that was admittedly sub-par, and hope not to come across the way that email did.
0
0
4
@bjorntopel I found out that the Monday after is a new bank holiday here.. I suppose I shall see you there :)
0
0
0
@nathanchance "developers will introduce [-Wmaybe-uninitialized] inadvertently and not realize it because GCC never told them about it" tbh stuff like this made me swap to clang-by-default. Got sick of lkp complaining about stuff that gcc missed.
0
0
2
Conor Dooley
conor
Heh, this would've been nice to have attended year ago:
https://fosdem.org/2023/schedule/event/pwm/
"The audience learns the general concept of PWMs, about the corner cases in their usage and driver design, and how to avoid the common pitfalls often pointed out to authors of new PWM drivers during the review process."
https://fosdem.org/2023/schedule/event/pwm/
"The audience learns the general concept of PWMs, about the corner cases in their usage and driver design, and how to avoid the common pitfalls often pointed out to authors of new PWM drivers during the review process."
0
1
1
@gmarkall You running mainline + patches, or the tree they ship? Either way, yell if something that should work doesn't? I figure stuff ship works for but probably hasn't see diverse use.
They sent me over some docs, so I was able to look a bit more closely at the power management unit patchset - there's not a lot of drivers to compare against there so that one is mainly what worried me.
They sent me over some docs, so I was able to look a bit more closely at the power management unit patchset - there's not a lot of drivers to compare against there so that one is mainly what worried me.
1
0
0
@gmarkall Ahh, figured. My internal gauge of LLVM build times comes from running https://github.com/ClangBuiltLinux/tc-build/build-llvm.py which builds all archs by default. 2 hours (with headroom to improve) for the single target build sounds promising in terms of being able to do native building of things.
0
0
0