3 ms·

Yeah XIP is the only way to go for small config these days. There's some nice QSPI controllers that helps there, however, it's still such a waste. What's forgo

Yeah XIP is the only way to go for small config these days. There's some nice QSPI controllers that helps there, however, it's still such a waste. What's forgotten about is the impact on readability in the kernel... Last week I was discussing with a colleague a patch needed for our SoC in the 8250 serial driver. In the IRQ handler, we needed to do an extra test... And my problem was that this test would be running on a bazillion machines if upstreamed, for about 0.000000001% chance of ever be executed, bar for our own low volume, industrial SoC. We'd add cycles to a critical code path for zero reason, and without conditional compile, nobody would know by reading the code. So, after mulling over it, we decided to get it upstream anyway at some point. The conclusion was that we didn't make these rules, we're just following them. Thing is, a lot of that stuff is happening; you have that vendor specific property that is tested, change a flag somewhere, and code all over use that flag for testing of features that have 0% chance of happening on that arch/machine. In the meantime, all that becomes code bloat, with codepath that are actually 'exceptions' bloating the code in a way you can't even 'see' them by reading the code. Sad? </rant>

jcelerier 9y ago
> And my problem was that this test would be running on a bazillion machines if upstreamed, for about 0.000000001% chance of ever be executed, bar for our own low volume, industrial SoC. We'd add cycles to a critical code path for zero reason, and without conditional compile, nobody would know by reading the code. That's a good reason why C++ is generally superior to C in embedded development: with C++, you can get at the same time compiler checks for the validity of your whole code to prevent bitrot (unlike macros), and ensure that the actual implementations will only have the actual code that is relevant to them - e.g. set your flags as constexpr variables in your device's struct, and have the tests run under `if constexpr` conditions. Devices without the flag set won't have the check compiled in, and others will. But oh well :)

jcelerier 9y ago

> And my problem was that this test would be running on a bazillion machines if upstreamed, for about 0.000000001% chance of ever be executed, bar for our own low volume, industrial SoC. We'd add cycles to a critical code path for zero reason, and without conditional compile, nobody would know by reading the code. That's a good reason why C++ is generally superior to C in embedded development: with C++, you can get at the same time compiler checks for the validity of your whole code to prevent bitrot (unlike macros), and ensure that the actual implementations will only have the actual code that is relevant to them - e.g. set your flags as constexpr variables in your device's struct, and have the tests run under `if constexpr` conditions. Devices without the flag set won't have the check compiled in, and others will. But oh well :)