• Mark Rutland's avatar
    locking/atomic: scripts: generate kerneldoc comments · ad811070
    Mark Rutland authored
    Currently the atomics are documented in Documentation/atomic_t.txt, and
    have no kerneldoc comments. There are a sufficient number of gotchas
    (e.g. semantics, noinstr-safety) that it would be nice to have comments
    to call these out, and it would be nice to have kerneldoc comments such
    that these can be collated.
    
    While it's possible to derive the semantics from the code, this can be
    painful given the amount of indirection we currently have (e.g. fallback
    paths), and it's easy to be mislead by naming, e.g.
    
    * The unconditional void-returning ops *only* have relaxed variants
      without a _relaxed suffix, and can easily be mistaken for being fully
      ordered.
    
      It would be nice to give these a _relaxed() suffix, but this would
      result in significant churn throughout the kernel.
    
    * Our naming of conditional and unconditional+test ops is rather
      inconsistent, and it can be difficult to derive the name of an
      operation, or to identify where an op is conditional or
      unconditional+test.
    
      Some ops are clearly conditional:
      - dec_if_positive
      - add_unless
      - dec_unless_positive
      - inc_unless_negative
    
      Some ops are clearly unconditional+test:
      - sub_and_test
      - dec_and_test
      - inc_and_test
    
      However, what exactly those test is not obvious. A _test_zero suffix
      might be clearer.
    
      Others could be read ambiguously:
      - inc_not_zero	// conditional
      - add_negative	// unconditional+test
    
      It would probably be worth renaming these, e.g. to inc_unless_zero and
      add_test_negative.
    
    As a step towards making this more consistent and easier to understand,
    this patch adds kerneldoc comments for all generated *atomic*_*()
    functions. These are generated from templates, with some common text
    shared, making it easy to extend these in future if necessary.
    
    I've tried to make these as consistent and clear as possible, and I've
    deliberately ensured:
    
    * All ops have their ordering explicitly mentioned in the short and long
      description.
    
    * All test ops have "test" in their short description.
    
    * All ops are described as an expression using their usual C operator.
      For example:
    
      andnot: "Atomically updates @v to (@v & ~@i)"
      inc:    "Atomically updates @v to (@v + 1)"
    
      Which may be clearer to non-naative English speakers, and allows all
      the operations to be described in the same style.
    
    * All conditional ops have their condition described as an expression
      using the usual C operators. For example:
    
      add_unless: "If (@v != @u), atomically updates @v to (@v + @i)"
      cmpxchg:    "If (@v == @old), atomically updates @v to @new"
    
      Which may be clearer to non-naative English speakers, and allows all
      the operations to be described in the same style.
    
    * All bitwise ops (and,andnot,or,xor) explicitly mention that they are
      bitwise in their short description, so that they are not mistaken for
      performing their logical equivalents.
    
    * The noinstr safety of each op is explicitly described, with a
      description of whether or not to use the raw_ form of the op.
    
    There should be no functional change as a result of this patch.
    Reported-by: default avatarPaul E. McKenney <paulmck@kernel.org>
    Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
    Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: default avatarKees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20230605070124.3741859-26-mark.rutland@arm.com
    ad811070
set 255 Bytes