Seems fine... what compilers / build env hits this?

Overall this looks good, up to my ability to review it. A couple of really minor nits, plus a question based on a pull request that came in over the weekend.

So I've taken a look at this, and it's fine.
emax@, the original BT author things its fine as well.
We should commit this.
I think just zeroing it all and moving on is the right thing to do. The old code is clearly wrong and the new code sets all the right bits ...

I don't understand this.
I wonder why both of these aren't always depends...
Also, I can't find the places where those two modules are built in this review chain...
So @allanjude what's the story.

So this isn't needed for what I'm doing... it looks interesting. What's the status?

https://reviews.freebsd.org/D45765 replaces this.
I think this should be Author: allanjude, and that will be what I push (even though I tweaked it in a tiny way, it's not enough to get to co-author)

This no longer applies.
I've create a new review
https://reviews.freebsd.org/D45764
and closing this one.

See https://reviews.freebsd.org/D45763 for what little missing functionality was missing.
As always, flag anything I missed, etc

Most of this change has been re-committed / re-implemented.
The only thing this adds that isn't in the tree is length checks, which I've added.

commit f689cb23b2782d0d0f586bcfabbad68f728ed1df
Author: Val Packett <val@packett.cool>
Date:   Wed Apr 7 15:05:49 2021 -0500

This revision by Val Packett implements this functionality in a better way.
If I've missed something, please let me know, file a new differential, tag me, etc

commit a29bff7a5216bd5f4a76228788e7eacf235004de
Author: Val Packett <val@packett.cool>
Date:   Wed Apr 7 14:46:29 2021 -0500

This review is OBE. Other changes implement this in main.

In D28707#1039838, @tuexen wrote:

Is there some interest in getting IPMI working on arm64 machines? When testing FreeBSD current on two Ampere systems it does not work. Some of the smaller patches are not yet committed. Is there an intention to get this working?

Looks like Drew already landed this:

commit ba0e4d7971e05ee64281a4fc49a2fb408c8ad816
Author: Andrew Gallatin <gallatin@FreeBSD.org>
Date:   Wed Nov 15 11:11:53 2023 -0500

This has all been committed. Commandeering Revision to close it.

In D28737#970427, @gallatin wrote:

It seems like this was obsoleted by:

commit ee97f198b42d50437f87aa4111d478eca2a5be16
Author: John-Mark Gurney <jmg@FreeBSD.org>
Date: Wed Feb 22 02:27:37 2023 +0000

Support SMBIOS v3 for 64-bit entry systems

Summary:
Under QEMU on arm64 systems, the smbios table is above 4GB
requiring a 64-bit address to access.

Reviewers: manu

Subscribers: imp, bcran, dab

Differential Revision: https://reviews.freebsd.org/D38721

why the crazy vm_offset_t instead of uintptr_t??

Looks good. I can't answer the wrapper question definitively, but I suspect it will be fine.

I haven't heard of anybody building i586 or i486 in a while. That suggests that it isn't com.on / interesting enough to highlight here.

In D45734#1043144, @khorben_defora.org wrote:

Would it be more clear or accurate to mention the "Pentium MMX" instead or in addition to the Pentium Pro?
It was much more common and known to the public than the Pentium Pro.

This looks good to me

Is this used in .h file or .c files?

I think this is in the TI kernel that's kinda on the way out unless it gets fixed... and oskar has been fixing it up...

In D45661#1042261, @kib wrote:

In D45661#1042253, @markj wrote:

In D45661#1041742, @kib wrote:

I think malloc_large() and this one need to check that round_page(size) does not overflow.

Hmm, kmem_malloc* also don't check for overflow. Presumably those functions and malloc_size() should KASSERT(round_page(size) >= size);?

It would be useful, but only for debug kernels. For instance, an unhandled unbound allocation leaking from some device' ioctl is my worry there.

The current text is moderate. If anything it is too weak. While the generic philosophy has been to eschew advice, this crosses the lone into useful, nonobvious information necessary to successfully use the tool....

In D45658#1041770, @manu wrote:

In D45658#1041688, @emaste wrote:

Seems reasonable to me, if we have ukbd compiled in as well. Can you also indicate in the commit message what we get out of using hkbd instead of ukbd?

I thought my message was clear on this, can you suggest better wording then ?

Ah, that's different. I'll just punt

In D45651#1041634, @brooks wrote:

I think the C++ case will now expand, but fail to link

tinyc doesn't support cplusplus, so this is a nop for that. However,
some future compiler might support C and C++, but not support symver, so
go ahead and make this future proof.

In D45653#1041605, @brooks wrote:

I think the question "should these remain when we can count on the __attribute__((attribute)) existing?" is a question worth asking, but removing them is going to be a long and bumpy road as we've had these for a long time. In the mean time I see no value in retaining support for compilers that can't realistically work. It's just clutter.

remove extra change

Move to the more preferred way to gate this stuff.

Ideally, we'd just not define sym_compat and omit the first symbol that uses it when sym_compat isn't defined. That's the most straight forward thing to do. But that review got mired down and I abandoned it and lost the branch locally somehow. I'll rework this to do that, though.

Apart from the one mistakenly added hid kernel, I like it. But I hit approve because that mistake predates this change.

In D45653#1041463, @kib wrote:

I do not like this/object against the appoach. What is the point of having all that re-defines in sys/cdefs.h? Why not use GNUCC-ism attribute((something)) directly? It would be less confusing and less convoluted to see actual code feed to the compiler, from our sources.

IMO the point of cdefs.h is to hide compiler-specific features behind FreeBSD-specific features. If compiler cannot provide the feature, sys/cdefs.h should clearly state that at compilation stage.
In other words, I think it is mostly fine to do something like

#if defined(__GNUC__)
#define __freebsd_feature __gcc_feature
#else
#error compiler does not implement freebsd_feature
#endif

but not just assume that everything is GCC.

This obsoletes https://reviews.freebsd.org/D45650 btw and also fixes the problem.