@GrahamcOfBorg build chipsec linuxPackages.chipsec

Oops, ofBorg failed to build it because it doesn't work on ARM.

LGTM. Added a few nits for your consideration.

Another thing that occurred to me is, if I add both variants to my system will I end up with two copies of the userland tools in the system closure? It seems to me like I will, as different flags would produce different store paths. Perhaps the withDriver case ought to build only the driver. On the other hand, I'd hope hardlinking would resolve the space inefficiency ... so maybe not worth the effort.

Hmm, but it loads the driver on demand. We'd have to make sure it can find it if it's in a different derivation. I don't think the package is designed to be able to look for the driver elsewhere, I can look into it.
I didn't know a better way to make the driver optional other than including it in linuxPackages and top-level. Is there?

By loading on demand, I expect you mean calls modprobe? If so it should work as long as the package is added to boot.extraModulePackages (and the call to modprobe/insmod does not hardcode the module path). If it does hardcode the path, that can be patched out.

I think I was wrong to raise the concern about duplicated stuff in the system closure, I have not looked but extraModulePackages probably only copies kernel modules anyway. There will still be some wasted bandwidth & work in the linux driver+userspace scenario, however. This could be solved by simply defaulting withDriver = true when building for linux.

Yes exactly, calling modprobe.
But if we rely on boot.extraModulePackages we'd have to make it a module which is not the right thing to do because using chipsec is a one-off kind of thing.

But can you just default to building the driver on Linux? I don't think you can, because you also need to get the exact kernel passed that used on the system. Hence linuxPackagesFor to build it for a specific kernel version.

Is there precedent? Is there another package that's not just a kernel module but a program that brings its own kernel module that we package but don't have a NixOS module for? P.S. Looks like sysdig is in a similar situation.

Otherwise I think it's fine like this. We'll have to hope that people are looking for the linuxPackages.chipsec attribute if they notice that chipsec doesn't include the driver.

Thanks for discussing the details!