This seems to be the "final" version to review given the parent review is accepted.

Adding @dumbbell given the recent drm-kmod build issues after my changes to LinuxKPI as this will be interesting there (though a lot harder to introduce given drm-kmod also needs to compile on older branches).

Thankfully apply suggestions from @ziaee .
Given the changes in D60207 update the section of the man page to match the reality of the stack.

Adjust the code to LINUXKPI_FEATURES+= and add futher support.
Needless to say this makes the feature options also nicly grep-able.

In D60207#1387495, @kib wrote:

Might be LINUXKPI_FEATURES then? It is more aligned with the feature list that the variable takes.

In D60207#1387061, @kib wrote:

What if I'll change it one step further and call it LINUXKPI_ADD and we add GENSRC to that too along with INCLUDES?

Add the one from @emaste (thanks!) while still here.

In D60279#1385571, @imp wrote:

Just curious: What would it take to add support for these?

@emaste what's your VID combination?

Add another user supplied entry.

Alos please change the first line of the commit message to

LinuxKPI: firmware: ....

I've done the due diligence and it seems for all LinuxKPI versions we care about we can apply this.

This is not ideal yet and I hope you can help me to get it polished and move things in the right place but it feels a lot better (at least to me) having one source of truth rather than (n+1) man pages with a copy of the (longer) text.

In D60208#1382179, @ziaee wrote:

Some of this is stuff that we would normally keep on the wiki, I really like them being here in the tree instead. I think it's easier to see and maintain atomically.

Careful! We already have a native uuid_t! Someone should check if (a) we can use that and (b) possible conflict potential.

If you mark the requested change "done" I am am fine if @emaste or @dumbbell are fine too; I assume they know what the fb_getinfo is supposed to do and how it is supposed to be used.

In D60207#1381676, @emaste wrote:

The logic seems sound but somehow CFLAGS_LINUXKPI is odd to me, like CFLAGS_* should contain flags rather than be a boolean. E.g. we have CFLAGS_NO_SIMD= -mno-mmx -mno-sse...
Hrm, but we also have e.g. SSP_CFLAGS?= -fstack-protector-strong -fstack-clash-protection and that form is more common.
ADD_LINUXKPI_CFLAGS?

Please note there are a lot of commented out parts in there for drivers, etc. which do use LinuxKPI, which are in the tree, but not yet hooked up to the build.

I found out why this was not really working. I'll put a review up for fixing LINUXKPI_INCLUDES as soon as I put down linuxkpi.9 to document it.

Anyone on this fairly simple review?

Superseded by D59913

I have an old (non-stack) stack open (I believe from 2018) of which you would have been a reviewer:

Ok, very last call. It's not been December in almost a year soon and May is also gone for a while. 48 hours.

Can you please upload this with either arc or a patch from git diff -U9999 so context is available.

So let me ask: is this related to the "fictitious pages" mentioned in D58320? If so, how is the LinuxKPI part to be written/work in the future world order with a real 'struct page'?

Oh, I wonder how you can trigger this from the semi-native driver? What was @gallatin 's error case?

You should add something like:
Originally reported (and tested with D57430): Mark Millard <marklmi@yahoo.com> (current@ July 25 2026)

I have a full stack up for review for ages for PCI.

In D59608#1372437, @temcbun_gmail.com wrote:

@bz Could you please MFC this? :)

This has been lingering here for half a decade it seems. Anyone interested in looking into this / if it makes sense (take over the review)? Otherwise I'll abandon it in a few days.

Overcome by time and I am no longer interested.

The panic was fixed in bfed2417f472f87e720b37bdac9ffd75ca2abc54 ; the remainder I don't care anymore.

This has been sitting here for almost 2 years now. I am sure lines have changed from under it multiple times. Does anyone want to pick this up? Otherwise I'll abandon. It's quickly redone by anyone who wants anyway.

I'll not be the one beating iwx with a stick.

Ah found another one which seems ready for review @dumbbell @emaste

I still do not get how this is supposed to fully work but I assume the shortcut from before remains right. I'd say for me you can add: