Is this line needed? I don't know. None of my test builds seemed to care about the files I'm removing here.

Is this line needed? I don't know. None of the test builds I did seemed to care whether or not the functions below were defined.

Should this go before line 36? No, not if I want KASSERT to be defined.

Why are these defined? Well, this fixes the failure of buildworld on i386. To be clear, it fails already. This is just added so that I can compete that buildworld. Also, it might let someone include log2.h without libkern.h.

The one kernel config which uses this code is arm/conf/TEGRA124. Does your test build cover it?

Aside from order_base_2(), these are aliases of rounddown2(), roundup2(), and powerof2(). Which versions are kernel developers supposed to use? These aliases are generally used in drivers which are ported from Linux; can we not keep them in the linuxkpi?

If we keep them here, I'd prefer to use names that complement the existing param.h macros. It's not really ideal to have, e.g., roundup2() and roundup_pow_of_2() side-by-side. Drivers which use Linux interfaces, like mana, can pull in LinuxKPI includes if they need to.

I'm not sure what the names should be, but this patch also doesn't introduce any non-LinuxKPI consumers of these macros.

There are three places where this patch removes definitions of roundup_pow_of_two so that this new, common definition can be used. Those three drivers would be non-LinuxKPI consumers of that macro.

This patch is a response to this @alc comment in D45494:
"I would add a new #define/inline with a self-documenting name. If Linux already has such a #define/inline, I would borrow its name."

It's not clear to me I can make both of you happy here.

I think that rounddown_powerof2() would be more consistent with param.h. However, in the end, I also think that being consistent with Linux will probably save time for more people. Thoughts?

If someone is familiar with Linux, they can quickly look up the LinuxKPI definition and see the "native" name for it (presumably we'd have #define roundup_pow_of_two roundup_powerof2 or similar), so it's not obvious to me that they'd waste a lot of time.

I'm not doing the work here so don't want to argue very much. I'll just say that I tend to find code easier to read if it's consistently following one of native FreeBSD style or Linux style, and code which mixes the two is a bit jarring. This is just about a couple of macros, though, so either approach is fine with me.

The log2 implementation comes from sys/ofed/include/linux/log2.

The last commit to that file (before it was removed and the functionality was moved to linuxKPI dropped ____ilog2_NaN() and replaced it with -1. The commit by HPS just says:

Minor rework of ilog2() function.

The second commit to that file introduced the 66-line const handling ilog2 lines with no comment, but with the four underscores.

This web link: https://lwn.net/Articles/203596/
shows someone had this same code in the Linux kernel, also with the four underscores.

Ultimately, it comes from 2006 Red Hat code by David Howells. Only he knows why there are four underscores.

I'll make the pure2 dead change.

Linux got rid of ____ilog2_NaN about 8 years ago.

They did, because the gcc of that time couldn't optimize well in its presence.
https://code.googlesource.com/linux/torvalds/linux/+/474c90156c8dcc2fa815e6716cc9394d7930cb9c

Also, since the code was copied from Linux to FreeBSD, they redefined is_power_of_2 so that 0 was not a power of 2, where the current implementation we have produces an undefined result in that case.

Also, they got rid of the long list of const log values here:
https://code.googlesource.com/linux/torvalds/linux/+/2f78788b55baa3410b1ec91a576286abe1ad4d6a

I'll update with all those considerations in mind.