> E.g. would Linux accept code for drivers / architectures that are not available to the public?

Drivers is an unequivocal "yes". Here's an example -- from Google, in fact:

https://github.com/torvalds/linux/commit/e561bc45920aade3f8a...

Architectures is less likely. But the pendulum has swung away from "making your own architecture" anyways.

But hey, even with that example, the same mechanism got adapted to Chromebooks+Coreboot and now uses that same driver here:

https://github.com/torvalds/linux/commit/d384d6f43d1ec3f1225...

xcore (mentioned in that thread) is pretty obscure and still in trunk last I looked. Extra backends don't carry that much of a maintenance cost, mostly patching them up on api changes. Weirder targets hit bugs that the common ones don't so there's a benefit from having them in tree too.

I'm not sure that generalises beyond modular compilers though.

Given how ridiculously strict the Linux folks are being with the DXGKRNL stuff that MS is working on (which is public as part of WSLg), I would say definitely not.

I think that has more to do with DXGKRNL coming from Microsoft than any policy that would be applied to other contributers.

Other Microsoft contributions got into the kernel just fine.

And other thin veneers over closed source paravirtualized VM graphics acceleration pipes get in as well, even from companies that flagrantly violate Linux's license.

I think that it's a difference of subtree maintainer as to why some Microsoft code gets in and some is fought tooth and nail; you can't treat Linux developers as a monolith, and the graphics side is significantly more Microsoft adverse.