<lejonet>
qyliss: uhm, I built the kernel, without HW_RANDOM_VIRTIO=y, extracted the .config and put into a 4.19.60 kernel directory, and in menuconfig, there is nothing saying =y isn't allowed for HW_RANDOM_VIRTIO... so why the hell does the nix build of it disallow =y? (sure, this is a 4.19.60 kernel source, so maybe something changed in later 4.19 kernels, I will pull down latest 4.19 source and see with that)
<lejonet>
(tho I did add VIRTIO = yes, HW_RANDOM = yes and VIRTIO_MENU = yes, building with non-modified start-vm.nix to extract config from there)
<lejonet>
qyliss: Hmm, I found that the start-vm.nix that is right now, builds with HW_RANDOM=m, so HW_RANDOM=y and HW_RANDOM_VIRITO=y should work, but it seems like something ignores the HW_RANDOM=y part perhaps
<lejonet>
Could also be that something is forcing VIRTIO to m too, dunno what tho
<lejonet>
Sadly, I think this could be an ordering issue, the VIRTIO_PCI = yes gets applied later than HW_RANDOM_VIRTIO, so VIRTIO_PCI = yes haven't made VIRTIO=y yet, so when the script comes to HW_RANDOM_VIRTIO, VIRTIO is still m, thus HW_RANDOM_VIRTIO isn't allowed anything but m or n
<lejonet>
This also explains why your MODULE=yes worked, because then VIRTIO gets set to y before it reaches HW_RANDOM_VIRTIO
<lejonet>
Yeah, because the build does make defconfig first, which with MODULE=yes would set all defaults to y instead of m, and then runs --oldaskconfig...
<lejonet>
Basically, I think we'd need to patch the defconfig to get around this problem
<lejonet>
qyliss: I think I might've solved it, fairly bluntly tho. Luckily there is an argument to the kernel pkgs where you can give it the path to the defconfig, so I simply snagged the x86_64_defconfig, dumped it into a string, with your extra values appended to it, writeText and then do kernel'.override { defconfig = defconfig_var; }; and at least its compiling the kernel so far
<lejonet>
nope, it seems like it nuked half the settings instead, bleh
<lejonet>
I will see about finding what defconfig that nixpkgs usually use, and mod that, instead of the skeleton one that comes with kernel sources
<qyliss>
lejonet: I got it working with VOP=y and VOP_BUS=y
<qyliss>
After hours of trial, error, and insomnia
<lejonet>
qyliss: great fun isn't it? :P
<lejonet>
The whole kernel building is a whole bunch of duct tape, is all I can state
<qyliss>
This feels like a Kbuild bug to me
<lejonet>
Indeed
<qyliss>
I'll write them an email I guess
<lejonet>
I think Kconfig just goes in lexicographic order and recursively walks everything
<lejonet>
It would've been nice if it did a two-pass thing, first collect all the settings, dependencies and such, then apply the config things
<qyliss>
The Nix thing does do two passes
<qyliss>
I don't know what those are
<qyliss>
But it definitely runs Kconfig twice
<lejonet>
My guess from yesterday is first it does make defconfig to get the basic .config, then it does make <something, I think nconf> to customize everything
<lejonet>
Because *conf targets throw a hissy fit if .config doesn't exist already
<qyliss>
Ah I see
<qyliss>
That makes sense
<qyliss>
VOP is apparently "VirtIO over PCIe"
<lejonet>
oh, okay
<lejonet>
sooo, its basically like VIRTIO_PCI but emulates PCIe instead?
<qyliss>
Not sure
<lejonet>
or from the wording "VirtIO over PCIe" it sounds like it might be the opposite, the VirtIO protocol, but with PCIe as transport
<qyliss>
It's under the Intel Many Integrated Core (MIC) architecture overview
<qyliss>
pasted too much there but you get the idea
<qyliss>
An Intel MIC X100 device is a PCIe form factor add-in coprocessor
<qyliss>
card based on the Intel Many Integrated Core (MIC) architecture
<qyliss>
that runs a Linux OS.
<qyliss>
So yeah
<lejonet>
Yeah, also makes more sense then
<qyliss>
Doesn't look like something HW_RANDOM_VIRTIO should be depending on
<lejonet>
I was thinking about grabbing a MIC card a few years back, when a retailer sold out their stock at 90% discount
<lejonet>
Indeed
<lejonet>
And it technically doesn't directly depend on it at least
<lejonet>
Good that you got it working, my foray into the defconfig option of the kernel have yielded more questions than answers lol, because it almost seems like it doesn't do the 2 pass anymore if you just pass in a defconfig
<lejonet>
and if you do pass in both a defconfig and structuredExtraConfig, it does the 2-pass, but it seems to ignore the defconfig then...