This patch is against stable/14, not main

I very much want this (and for release media to start including a kernel.debug by default when possible, cc releng), but sys/conf/std.debug already exists on main. In particular, you've added a few extra _DEBUG options here which aren't in GENERIC. I think that's probably fine, but ideally we'd start by MFCing the commit which added std.debug.

I always have a GENERIC-DEBUG for stable branches, the content is similar. +1 for this.

In D46871#1069247, @markj wrote:

This patch is against stable/14, not main

I very much want this (and for release media to start including a kernel.debug by default when possible, cc releng), but sys/conf/std.debug already exists on main. In particular, you've added a few extra _DEBUG options here which aren't in GENERIC. I think that's probably fine, but ideally we'd start by MFCing the commit which added std.debug.

I can (and should) start from that commit, but it changes the GENERIC configs, which isn't quite what we want on stable/14,stable/13.
I've done a cherry-pick along with major modifications and will update this review with that in a few minutes.

Do these configs automatically get built with tinderbox and universe make targets? If so, this looks good to me aside from some nits I commented on inline.

In D46871#1071719, @imp wrote:

I'm curious why BUF_TRACKING is on this list...

It's also in sys/conf/std.debug on main.

It changes the KBI so would create a bigger problem with not being able to load .ko's than it would solve.

We're going to have that problem anyway, between DEBUG and NODEBUG builds. I'm not sure why that's a concern.

It's rarely useful to tracking down issues and introduces a decent amount of overhead to boot. So on the w>hole, I think we'd be better off without it, but maybe there's some good reason to include it.

"It's enabled on main" is the extent of my reasoning. I don't particularly care about individual debug features, to be honest. I mostly only ever care about INVARIANTS and WITNESS, because those two are 95% of the value of a DEBUG build.
So I don't have particularly strong views here. I'm primarily interested in making it easier to build debug versions on stable branches, because it'll be more useful to build and test those than release versions.

In D46871#1071775, @kp wrote:

In D46871#1071719, @imp wrote:

I'm curious why BUF_TRACKING is on this list...

It's also in sys/conf/std.debug on main.

It changes the KBI so would create a bigger problem with not being able to load .ko's than it would solve.

We're going to have that problem anyway, between DEBUG and NODEBUG builds. I'm not sure why that's a concern.

It's rarely useful to tracking down issues and introduces a decent amount of overhead to boot. So on the w>hole, I think we'd be better off without it, but maybe there's some good reason to include it.

"It's enabled on main" is the extent of my reasoning. I don't particularly care about individual debug features, to be honest. I mostly only ever care about INVARIANTS and WITNESS, because those two are 95% of the value of a DEBUG build.
So I don't have particularly strong views here. I'm primarily interested in making it easier to build debug versions on stable branches, because it'll be more useful to build and test those than release versions.

The KBI concerns aren't very relevant in practice:

• most fields in struct buf are not affected, except the page array, and most consumers have no business poking around there,
• the size of struct buf is already dynamic, so consumers can't deal with arrays of them,
• buffer cache consumers never allocate bufs, that's handled by vfs_bio.c,
• there aren't many (any?) 3rd party modules that people care about that manipulate bufs.

In D46871#1071808, @markj wrote:

In D46871#1071775, @kp wrote:

In D46871#1071719, @imp wrote:

I'm curious why BUF_TRACKING is on this list...

It's also in sys/conf/std.debug on main.

It changes the KBI so would create a bigger problem with not being able to load .ko's than it would solve.

We're going to have that problem anyway, between DEBUG and NODEBUG builds. I'm not sure why that's a concern.

It's rarely useful to tracking down issues and introduces a decent amount of overhead to boot. So on the w>hole, I think we'd be better off without it, but maybe there's some good reason to include it.

"It's enabled on main" is the extent of my reasoning. I don't particularly care about individual debug features, to be honest. I mostly only ever care about INVARIANTS and WITNESS, because those two are 95% of the value of a DEBUG build.
So I don't have particularly strong views here. I'm primarily interested in making it easier to build debug versions on stable branches, because it'll be more useful to build and test those than release versions.

The KBI concerns aren't very relevant in practice:

• most fields in struct buf are not affected, except the page array, and most consumers have no business poking around there,
• the size of struct buf is already dynamic, so consumers can't deal with arrays of them,
• buffer cache consumers never allocate bufs, that's handled by vfs_bio.c,
• there aren't many (any?) 3rd party modules that people care about that manipulate bufs.

Hmmm... There are several fs modules that we care about. However, I don't think any of them manipulate b_pages, which is the only visible thing normally... and I don't think that there's any that hook into that #ifdef. So I'll withdraw my objection. I do think that it is a bit too high overhead, but I'll take a wait-and-see approach then.