@zx2c4, thanks for your PR! By analyzing the history of the files in this pull request, we identified @zohl, @joachifm and @dezgeg to be potential reviewers.

Nice to see your contribution! I'm happy to merge this, and agree with your assessment. @zohl is there a realistic alternative we should pursue? Do you still use these kernels?

Previously #18726

Seems to be still actively maintained (last commit yesterday). https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.14

Maybe we can increase the patch level version, if we can identify a compatibility with the corresponding lts release.

@grahamc, yes, I still use this kernel, but I don't mind of removing it.

There are at least two alternatives to v3.14 kernel:

• chromiumos kernel v3.18 [1]
• linux-samus kernel [2]

The first one builds and runs fine, but there is no sound support at all.
The second one requires some adjustments as when I tried it, not everything worked as smoothly as in chromuim's v3.14. I think this is the only proper alternative.

Fortunately, soon I'll have enough free time to look closely at it and finally get rid of v3.14 on my machine. This PR is a good call to action :)

FWIW, I still use very old version of nixpkgs as there were some changes in hardware detection at stage 1. And since I load the system from an external hard drive, it becomes unusable for me. (Loading from the internal drive should be fine.) That is another reason against v3.14 kernel.

[1] https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.18
[2] https://github.com/raphael/linux-samus

@Mic92 wrote:

Seems to be still actively maintained (last commit yesterday).
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.14

It's not maintained by kernel.org anymore. However, if you'd alternatively prefer to switch the .nix here to a more recent commit from the chromeos people, and then make sure to track their git repo carefully, that'd be a satisfactory solution to me. But IMHO it's easier and probably better to just get rid of ancient kernels.

Maybe we can increase the patch level version, if we can identify a compatibility with the corresponding lts release.

If you go this route, be very very certain you do this perfectly, since a lot of #ifdef hackery relies on you getting it perfect. O_o

linux-samus sounds like the better option. Also it should support sound out-of-the-box.

Great, I think we're in agreement then. Let's go ahead and merge this, and then after you can merge #25127?