Kernel configuration oddities #185
Replies: 3 comments 14 replies
-
|
Hey @MaxKellermann
Hope this explains a bit the background, where we come from and why lot of the things here are looking that "horrible" ;-) |
Beta Was this translation helpful? Give feedback.
-
|
"nobody has been thinking anything" ... keiner denkt hier irgendwas ... |
Beta Was this translation helpful? Give feedback.
-
|
This just means "was found by try'n'error without knowing what they were doing". That's the kind of reply I got every time I asked "why did you do it this or that way". |
Beta Was this translation helpful? Give feedback.
-
|
OK ... understand your point. So let's improve the quality of the source as well as the way we use Yocto for getting a good and stable image :-) |
Beta Was this translation helpful? Give feedback.
-
|
An example I have just been trying to wrap my head around: What the ... this is an obviously malformed address! How can this ever work? What use is this? The first time I could find this in git was from 2015 on branch "next" in commit 05ad8afe8563ae#diff-dcd5bbd27701ee5f34b98c5c987f05acb796e00b422798c17665afa74fd2aff3R29 .... but this commit is so crowded, and this particular change still doesn't appear to make sense. I guess that this bad value was created in 2015 and from there, it was copied everywhere by everybody, and nobody ever understood why it is that way. I don't say this to criticize anybody - I want to understand why it was added - always thinking that maybe I am wrong and missing something! If I know it really makes no sense, it is simple to remove it. |
Beta Was this translation helpful? Give feedback.
-
|
It seems it is never used anymore ;-) But I think as rule of thumb, most of the strange things in the code are mistakes or dirty hacks. |
Beta Was this translation helpful? Give feedback.
-
|
@MaxKellermann I think most of configuration you have listed are there not by conscious decision, but because it was like that by default or by accident and nobody complained. It makes sense for USB device drivers to be in modules because people connect various devices and there is no particular list of what can be connected to openvario. If someone wants to connect a printer, why would we prevent that? Note that not all devices are useful while you're flying, some are useful when you're on the ground and sending your logs to the scorer (for example). For the other devices and features you listed - in my opinion we don't have to keep them enabled. I don't know anything that would depend on them. |
Beta Was this translation helpful? Give feedback.
-
There are lots of default options which are useless for OpenVario (and I'll submit a PR to remove them), but the options I posted here are not default options - they were explicitly enabled. I was asking because I wanted to know which ones of those can be disabled - maybe somebody really wanted to use a USB printer ...
None of what you wrote explains why those are modules. Modular kernels are hard to update; the kernel is on the boot partition, but the modules are on the root partition, and both must match exactly (not just the kernel version, but also many build options). This is fragile, so there must be a good reason to build a modular kernel. I see none, but I thought maybe somebody knows a good reason I don't see.
Does that mean you would like to keep the USB printer driver? Anybody who wishes to have certain very exotic modules can build their own kernel; it's open source after all. But I'm not convinced that a vario should have a USB printer driver, just in case somebody wants to print something. (OpenVario doesn't even have userspace printing support - but the same way you could argue that the next firmware build should ship with CUPS...) |
Beta Was this translation helpful? Give feedback.
-
Again, the only reason I can think of is by accident. I don't know any specific reason why most of these options are enabled. That said, please keep in mind that Openvario is a DIY electroincs project. People do creative things with their devices.We should not limit their creativity without a really good reason.
Having them as modules means we don't have to load all the possible usb drivers into the memory. It also means those drivers will not conflict with each other. This is also a set up that is known to work. All desktop linux kernels (I know) are modular, and they are getting upgraded without problems. Modular kernels are in production since forever and keeping kernel and modules in sync is a long time solved problem. Also, linux kernel is not something we have to update very often. Unless we are fixing the kernel itself (like we had to do couple of years ago), a kernel version can stay with whatever yocto version provides.
I don't have any strong opinion about the printer driver specifically. However, is there any good reason to explicitly disable it? Should we review each an every driver and decide whether it makes sense to have it on OV or not? I don't think so. It doesn't cost us anything to provide all the USB drivers that linux supports. However, shipping CUPS with OV and making sure printing actually works will cost us a lot of effort, therefore I don't think we should do that, since noone has found a good use for it so far. |
Beta Was this translation helpful? Give feedback.
-
Yes, we have a 1-wire interface on Openvario. It uses a DS2482-100 I2C to 1-Wire bridge, don´t know if this requires the 1-Wire kernel module or not. Maybe @linuxianer99 knows more about this bridge? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, i think this is used by Openvario (on sensorboard) |
Beta Was this translation helpful? Give feedback.
-
|
OK, when we re-add 1-wire support to the kernel config, the |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
I tried to make sense of the OpenVario kernel configuration (https://github.com/Openvario/meta-openvario/blob/hardknott/recipes-kernel/linux/linux-mainline/arm/defconfig); it was written in a rather cumbersome way: instead of using
*.cfgdeltas to configure individual aspects in a modular way, like Yocto kernel recipes are supposed to do it, there's a full copy of the kernel configuration which pretents to be the "defconfig". Of course, that's very difficult to port to new kernels, and makes it hard to support different hardware platforms. (I stumbled upon that because I have no Cubieboard 2, and wanted to quickly port it to my Cubieboard 1 so I can test OpenVario builds there.)So I converted the kernel configuration into a delta to the vanilla defconfig, and fond some oddities:
CONFIG_CMA) for OpenVario?These options are disabled in the default kernel config - they were explicitly enabled for the OpenVario custom kernel config. That's why I'm asking - who thought these options were useful for OpenVario?
They are part of the "initial commit" (6d9a704) made by a guy called "build" (on host "build.fritz.box", huh??) just 3 years ago in 2019. I thought OpenVario was much older than 2019 - why is all the commit history of meta-openvario before 2019 lost?
(Related PR: #186)
Beta Was this translation helpful? Give feedback.
All reactions