On Fri, May 12, 2023 at 06:03:26PM +0100, Mark Rutland wrote: > On Fri, May 12, 2023 at 09:01:27AM -0700, Paul E. McKenney wrote: > > On Fri, May 12, 2023 at 02:18:48PM +0100, Mark Rutland wrote: > > > On Thu, May 11, 2023 at 12:12:16PM -0700, Paul E. McKenney wrote: > > > > On Thu, May 11, 2023 at 06:10:00PM +0100, Mark Rutland wrote: > > > > > I think that we can restructure the ifdeffery so that each ordering variant > > > > > gets its own ifdeffery, and then we could place the kerneldoc immediately above > > > > > that, e.g. > > > > > > > > > > /** > > > > > * arch_atomic_inc_return_release() > > > > > * > > > > > * [ full kerneldoc block here ] > > > > > */ > > > > > #if defined(arch_atomic_inc_return_release) > > > > > /* defined in arch code */ > > > > > #elif defined(arch_atomic_inc_return_relaxed) > > > > > [ define in terms of arch_atomic_inc_return_relaxed ] > > > > > #elif defined(arch_atomic_inc_return) > > > > > [ define in terms of arch_atomic_inc_return ] > > > > > #else > > > > > [ define in terms of arch_atomic_fetch_inc_release ] > > > > > #endif > > > > > > > > > > ... with similar for the mandatory ops that each arch must provide, e.g. > > > > > > > > > > /** > > > > > * arch_atomic_or() > > > > > * > > > > > * [ full kerneldoc block here ] > > > > > */ > > > > > /* arch_atomic_or() is mandatory -- architectures must define it! */ > > > > > > > > > > I had a go at that restructuring today, and while local build testing indicates > > > > > I haven't got it quite right, I think it's possible: > > > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=atomics/fallback-rework > > > > > > > > > > Does that sound ok to you? > > > > > > > > At first glance, it appears that your "TODO" locations have the same > > > > information that I was using, so it should not be hard for me to adapt the > > > > current kernel-doc generation to your new scheme. (Famous last words!) > > > > > > Great! > > > > > > > Plus having the kernel-doc generation all in one place does have some > > > > serious attractions. > > > > > > :) > > > > > > > I will continue maintaining my current stack, but would of course be > > > > happy to port it on top of your refactoring. If it turns out that > > > > the refactoring will take a long time, we can discuss what to do in > > > > the meantime. But here is hoping that the refactoring goes smoothly! > > > > That would be easier all around. ;-) > > > > > > FWIW, I think that's working now; every cross-build I've tried works. > > > > > > I've updated the branch at: > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=atomics/fallback-rework > > > > > > Tagged as: > > > > > > atomics-fallback-rework-20230512 > > > > Thank you very much! > > > > I expect to send v2 of my original late today on the perhaps unlikely > > off-chance that someone might be interested in reviewing the verbiage. > > I'll be more than happy to, though I suspect "late today" is far too late today > for me in UK time terms, so I probably won't look until Monday. Works for me! > > More to the point, I have started porting my changes on top of your > > stack. My thought is to have a separate "."-included script that does > > the kernel-doc work. > > I was thinking that we'd have a gen_kerneldoc(...) shell function (probably in > atomic-tbl.sh), but that's an easy thing to refactor after v2, so either way is > fine for now! Good point, will make that happen. Easy to move the code, so might as well be v1. ;-) > > I am also thinking in terms of putting the kernel-doc generation into > > an "else" clause to the "is mandatory" check, and leaving the kernel-doc > > for the mandatory functions in arch/x86/include/asm/atomic.h. > > My thinking was that all the kernel-doc bits should live in the common header > so that they're all easy to find when looking at the source code, and since if > feels a bit weird to have to look into arch/x86/ to figure out the semantics of > a function on !x86. > > That said, if that's painful for some reason, please go with the easiest option > for now and we can figure out how to attack it for v3. :) I will give it a shot. Thanx, Paul
