On Wed, Oct 03, 2018 at 01:49:25PM +0200, Oleksandr Natalenko wrote: > On another hand, the users of embedded devices, mentioned by Linus, should > already know what scheduler to choose because dealing with embedded world > assumes the person can decide this on their own, or with the help of > abovementioned udev scripts and/or Documentation/ as a reference point. That's not an entirely realistic assessment of a lot of practical embedded development - while people *can* go in and tweak things to their heart's content and some will have the time to do that there's a lot of small teams pulling together entire systems who rely fairly heavily on defaults, focusing most of their effort on the bits of code they directly wrote. You get things like people taking a copy of an embedded distro at some point and then only updating components that they specifically want to update like the new kernel with the drivers for the SoC in the new product. > So I see no obstacles here, and the choice to rely on udev by default sounds > reasonable. There's still a good number of users where there's a big discoverability problem here I fear. We have this regularly with the arm64 fixups for emulating old locking constructs that were removed from the architecture (useful for running old arm binaries on arm64 systems), that's got a Kconfig option but also requires enabling at runtime. I've had to help several users who were completely frustrated trying to get their old binaries working having upgraded to a kernel with the option, turned it on in Kconfig and then being unaware that there was also this hoop userspace had to jump through. This is less severe as it's only a performance thing but still potentially annoying.
Attachment:
signature.asc
Description: PGP signature
