LinuxKPI: add cleanup.h for guard DEFINE_GUARD/guard.

[bz]

Summary

iwlwifi v6.11 started to use guard(). _T in the implementation needs
to be exposed to the driver which uses it in DEFINE_GUARD().

Given this is the first instance of attribute(cleanup) in the tree:

• gcc has support for it since at least 2003-06-04 (0bfa5f65bfb186f10d43304946fd7fcd69988732)
• llvm gained support on 2009-01-31 (d277d790e0f6f23043397ba919619b5c3e157ff3, llvm-svn 63462).

Sponsored by: The FreeBSD Foundation
MFC after: 3 days

[emaste]

sys/compat/linuxkpi/common/include/linux/cleanup.h

13

Since this will be the first use of this we probably want a note about compiler support (either in comment or in the commit message), even if the note is not specific versions and just that it has been supported for quite some time in Clang and GCC (if that's the case).

17

might want to clarify this comment, the "scare quotes" around "excellent" might not be universally understood to indicate this is actually not excellent.

[bz]

sys/compat/linuxkpi/common/include/linux/cleanup.h

13

I don't know if it is the first use but I looked up at https://clang.llvm.org/docs/AttributeReference.html#cleanup that clang supports it. I was hoping they would list from which versions; is there an easy why but looking at the source or going back version by version in the docs to see when it appeared?

[bz]

sys/compat/linuxkpi/common/include/linux/cleanup.h

13

Took a bit but I went and checked.. if I read the commits and code correctly:

• gcc has support for it since at least 2003-06-04 (0bfa5f65bfb186f10d43304946fd7fcd69988732) [not sure it it was there earlier already].
• llvm gained support on 2009-01-31 (d277d790e0f6f23043397ba919619b5c3e157ff3, llvm-svn 63462)

So should also be save to MFC to all supported branches.

Should I mention them specifically like this or keep it general? I think 'd prefer the commit message then it's found in the history and not buried in code.

17

I'll update it.

[emaste]

Should I mention them specifically like this or keep it general? I think 'd prefer the commit message then it's found in the history and not buried in code.

Since you looked it up might as well keep the version info. I'm fine with putting it in the commit message.

[bz]

Update comment to be less judgemental and more of a general warning.

[bz]

Updated.

[emaste]

OK