linux-asahi: remove unnecessary kernel configuration #10
Conversation
this removes various options from the Asahi kernel configuration that are very unlikely to ever be missed. This includes: - ancient filesystems - ancient USB devices - buggy networking code - a couple of types of kernel error injection (we have enough normal kernel errors, thanks) - CAN bus development - GPS support - SCSI jukebox support - USB tablet support - infrared Additionally, we decrease the maximum number of sound cards from 32 to 8.
|
...are you sure about all this?. while there are some reasonable changes here, out of this, i personally use:
and that's just skimming the list. this seems like a big chunk of stuff to just turn off, especially since you didn't really properly summarize what was disabled. there were a lot more SCSI things disabled than just jukebox support, for example. |
Every probability distribution has some interesting data points a few standard deviations out. 🤯 As this was targeted towards the default Asahi kernel, the focus was on things that were difficult/impossible to connect to an Apple Silicon Mac, things that are ancient and obscure, and things that constitute unnecessary kernel attack surface.
This is over 30 years old and lightly maintained.
You use sgi partition tables on modern Linux systems?!
This is a significant source of kernel CVEs.
Either you are an automobile security researcher, or you are involved in unholy eldritch ceremonies.
I think I'm being trolled on April Fools' Day at this point.
Maybe I went too conservative here. As @marcan also does audio engineering, perhaps he also has a data point to share.
The SCSI things I turned off were because I deemed them unlikely to be plugged into an Apple Silicon Mac by the 99% of users who don't realize they could probably buy a Thunderbolt-to-PCIe adapter and negate a lot of my assumptions. If you are in the 1% of users whose workflow is damaged by these changes, you are likely also in the 1% of users who know how to manually configure a Linux kernel and rebuild it yourself. 🤓 |
|
I didn't know there was a Anyway, I'm typing this message on my M1 mini using that same monitor (first introduced to Asahi development at AsahiLinux/m1n1#159 (comment)), and now I can happily control the backlight from plasmashell. Thanks for tipping me off by removing the driver! Seriously, though, these changes are spread across several different domains and don't strike me as necessarily considering that many niche, yet archetypal, usage patterns exist that you may not have knowledge of. Let me illustrate with some of the discussed examples:
The SCSI2SD is a SCSI drive emulator commonly used by hobbyists in SGI MIPS systems. The SD card used with it can easily be removed, and I have manipulated such cards from Linux on a variety of occasions, even mounting the SGI XFS partition natively.
CAN is well put to use in myriad embedded applications, both on hobbyist and professional scales. It's by no means limited to automotive use, or obtuse rituals. I was also particularly struck by the device mapper target removals and similar, especially those that see use outside of testing (e.g. dm-cache, which I was considering for small-internal/large-external drive configuration on my 256G Mac mini), though the testing targets are just as important for filesystem developers, etc. Anyway, I don't mean to harp on, but proposing a heterogeneous batch of config changes without even calculating a size/performance justification leaves a bad taste in my mouth. Obviously the choices are up to the project, and may depend on the goals of Asahi-the-distribution (is it intended to be a stable, general OS choice, or merely a jumping-off point? is being nearly identical to ALARM more important to present an upstream-like experience?). But for the moment, I wanted to share my perspective and make a few points I thought were salient. Reducing kernel attack surface is noble though, and in some cases it does make sense, I'll give you that. Also, comprehensively configuring a distribution kernel is hell, and you have my sympathies. |
|
i don't do april fools. i am an embedded software developer, both by trade and hobby. given that context, i think CAN and SLIP should make much more sense (on a constrained system, SLIP has a lot less overhead, and its downsides don't matter much). and yes, i have worked in the automotive space, but I currently do not. CAN is used outside of that space as well. GPS is also something that ends up in use in my industry, and was a central concern at a previous employer of mine. my job is made quite convenient by the fact that most of what my coworkers and i require, the above items included, can already be found in distro kernels. on most distros, maintaining your own kernel config can be rather annoying, and some clients i work with cannot build their own kernels due to corporate restrictions (thankfully i usually am not under this restriction), so what they have in the distro kernel is all they get. this kernel configuration most certainly counts as a distro kernel. since my employer does sometimes purchase macs, it is not out of the question that my coworkers or I could at some point in the future be doing our work from M1 hardware running Asahi. it would be nice if the things we need are in it, should that happen. my use of SGI partition tables is the same as that of @Skirmisher and my reason for JFS is similar (it's nice to be able to read ArcaOS partitions from other machines) |
I am eager to apply to this corporation that doesn't allow you to replace the stock distro kernel, but does allow you to type Anyway, count me chagrined. I'll leave this pull request open, in case Hector has a different philosophy towards this (seeing as he's the one of the people rebuilding the Asahi kernel the most and may appreciate build-time improvements). |
i'm confused- does this somehow make the kernel take half the time to build or something? what benefit is there to this? |
|
To quote Spock “The Needs of the Many Outweigh the Needs of the Few”. I have just compiled a custom kernel and it took almost 2 hours on an M1 Pro with the default config (no docs). I too would like to see a sensible .config file. I don't think its fair to collectively waste everyone's times compiling subsystems that are unlikely to ever get used by most users. If you need something special, I don't understand why you can't just turn it on. Obviously there will be some give and take finding a balance point. |
How did you compile the kernel? it should not take 2 hours. rebuilding |
|
Our job is not to ship cut-down kernels; we're using a kernel config derived from upstream ALARM intended to support as many users as possible without recompilation. For example, the only reason we don't have the entire world of PCI drivers compiled is because there is no Thunderbolt support yet. Once that's in, I will enable every PCI driver under the sun as most distros do. If you would like to have a slimmed-down kernel you are certainly free to compile your own, but there is no "sane" slimmed-down config because invariably every person who wants that (which includes myself) has a different idea of what should go in and what shouldn't. That's why I compile my own kernels for my main systems, and you should too. The linux-asahi package will remain generic and with wide support for hardware, even weird stuff. FWIW, compile times are 4-5 minutes on a 10-core M1 Pro for me. That's a non-issue. |
this removes various options from the Asahi kernel configuration that are very unlikely to ever be missed. This includes:
Additionally, we decrease the maximum number of sound cards from 32 to 8.