… > +++ b/include/linux/cleanup.h > @@ -4,6 +4,157 @@ > > #include <linux/compiler.h> > > +/** > + * DOC: scope-based cleanup helpers > + * > + * The "goto error" pattern is notorious for introducing … Will any other label become more helpful for this description approach? > + * this tedium … Would an other wording be more appropriate here? > + * … maintaining FILO (first in last out) How does this text fit to your response from yesterday? https://lore.kernel.org/all/6601c7f7369d4_2690d29490@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.notmuch/ > + * … If a function > + * wants to invoke pci_dev_put() on error, but return @dev (i.e. without > + * freeing it) on success, it can do: > + * > + * :: > + * > + * return no_free_ptr(dev); > + * > + * ...or: > + * > + * :: > + * > + * return_ptr(dev); … Would this macro call be preferred as a succinct specification (so that only the shorter one should be mentioned here)? https://elixir.bootlin.com/linux/v6.8.1/source/include/linux/cleanup.h#L78 > + * Observe the lock is held for the remainder of the "if ()" block not > + * the remainder of "func()". I suggest to add a word in this sentence. * Observe the lock is held for the remainder of the "if ()" block * (and not the remainder of "func()"). > + * the top of the function poses this potential interdependency problem I suggest to add a comma at the end of this line. > + * the recommendation is to always define and assign variables in one > + * statement and not group variable definitions at the top of the > + * function when __free() is used. I became curious how code layout guidance will evolve further also according to such an advice. Would you like to increase the collaboration with the macros “DEFINE_CLASS” and “CLASS”? https://elixir.bootlin.com/linux/v6.8.1/source/include/linux/cleanup.h#L82 Regards, Markus
