sys/dev/random/fenestrasX/fx_pool.c
169–211	I don't think these changes make sense. This table is only used to check `entc_cls->entc_src_cls` for some value today. Removing these values makes that pointer null, causing a crash instead.
sys/dev/random/random_harvestq.c
664–689	It seems like a lot of faff to save a few bytes of strings in the rodata section, and maybe cause a nullptr crash.
sys/sys/random.h
93–116	I don't think make the enum order platform-specific makes sense.

This revision now requires changes to proceed.Thu, Oct 23, 7:22 PM

sys/dev/random/fenestrasX/fx_pool.c
169–211	I guess I'm not following why. How would entc_cls get a value that is processed for these entropy sources #ifdef'ed out? Can you help direct me to the line(s) of code where a NULL pointer would be gotten?
sys/dev/random/random_harvestq.c
664–689	I'm not trying to save RODATA space. I'm trying to come up with something that can go into 15.0. The i386-only sources are useless in 15.0, but due to "deprecation process" we can't delete them from 15's sys/ yet. This was the compromise with release engineering. My goal in the approach is to have an entropy source ordering that will be the same between 16-current and 15-stable (other than additions at the bottom in 16-current -- to address your kinda-is-an KBI change). I'm trying to make it so that output from 'sysctl kern.random' doesn't show sources that have no relation to the platform being used. Also, to make setting the harvest mask more applicable to the platform being used. I'm also trying to reduce diffs to Juniper's code - which ran out of the 32 slots since so many are used for useless things on AMD64 and ARM64.
sys/sys/random.h
93–116	Please explain more, what about the order makes sense?

sys/dev/random/random_harvestq.c
664–689	I think it is pretty trivial to widen hc_source_mask to 64 bits for (3).
sys/sys/random.h
93–116	I don't think enum variant 19 corresponding to different sources on amd64 vs i386 vs powerpc vs aarch64 makes much sense.

sys/dev/random/random_harvestq.c
664–689	That doesn't fully help Juniper with our FIPS-140-3 changes to /dev/random. We have to report accounting for all possible entropy sources. That's 4x lines of accounting information for each entropy source. I'm trying to reduce noise and complexity for FIPS-140-3/CC certification. There are at least 3 commercial entities I know of that needs FIPS-140-3/CC certification. I'm working to upstream what Juniper's had to do per the evaluation labs. Also, why would you want the harvest mask to be even harder for someone to come up with if they want to change the defaults?
sys/sys/random.h
93–116	Sorry, I cannot fully parse this statement. I also just don't understand why we would not want to separate out the machine-dependent sources. To flip it around, what is the harm in doing this?