Originally posted by rabcor
View Post
So there are two ways a new open source driver in the Linux kernel is made.
1) developer maintaining the driver adds new features and so on.
2) developers maintaining the kernel core alter something and the driver is altered by Semantic Patch to match the change.
Yes its that number 2 that makes Linux kernel updating that also updates all drivers include with the kernel not to suffer from the Windows problem of update kernel have lot of random drivers fail.
Also mainline Linux kernel developer have different tools they can use to inspect how a function is used by all drivers include in the kernel. This is very useful to the core developers to know how X function is really used.
Also the Linux kernel release cycle is not that slow with a release every 9 to 10 weeks. Slow include of a driver into the Linux kernel mainline is not commonly due to the the release cycle. The reality is that 9 to 10 weeks is way shorter than most hardware release cycles. Vendors wanting to keep there next release secret is a bigger reason but its not the biggest reason. The most common reason for a driver to be slow to be in the mainline Linux kernel is failure to pass peer review because their are spot-able errors in the code base. Yes this is common automated bot checking the code and putting out a stack coding defects that have to be fixed.
Yes you have people like birdie who say they want proper CI/QA/QC and not being ware that is the key reason why drivers can be slow to get into mainline Linux is CI/QA/QC of the kernel finding problems with the driver parties want to upstream forcing the driver to go back and be repaired. So lot of cases the open source drivers that are not in Linux kernel mainline have stability problems.
Yes "no sense" on the delay into mainline Linux is not exactly true there is a reason to it. To perform CI and QA to a decent standard does take time same with fixing all the faults a decent CI and QA solution is going to find. Yes this is a higher quality bar than Microsoft driver signing and this happens to cause a delay in deleivery.
rabcor the hard reality is a non mainlined linux driver is going to be on average lower quality because of the level of Continuous Integration and Quality Assurance that is performed by the mainlining process being very high standard. I am not saying there should not be methods to backport drivers from mainline to older kernels more effectively and that their should not be methods to allow installing drivers from the developer of that drivers kernel tree.
Most people are not aware that AMD, Intel and so on developers maintains their own Linux kernel trees that they update when they like and sync to mainline. Yes the developer of the driver kernel trees there are generally lower quality than the mainline kernel tree because that automated bots like Intel 0-Day automated testing does not run against all kernel trees. https://01.org/blogs/2018/0-day-ci-test Yes there are many company bots that run over the Linux kernel mainline looking for defects.
Yes the ideal world is that all drivers get mainlined at some point with Linux so they get the most quality control possible performed. Remember tools like intel 0-day don't work on binaries you need source code.
rabcor most likely you want all drivers mainlined. Yes it costs quite bit a first due to how much drivers have to be fixed to get into mainline. Faults that developers get way with in non mainline code are not going to fly in mainline Linux kernel.
Yes your most likely want the ability to backport dependable from the mainline branch to LTS branchs of the Linux kernels as your primary option and the developers own kernel tree as your secondary. Remember this order would to get decent quality drivers. Decent quality as in properly validate against common human coding errors and even against many highly complex coded errors.
Like it or not there is very valid reasons for drivers to be mainlined.
Heck even if a older version is mainlined to the one you are using at least that would still provide the Linux kernel developers with at least some idea of how the driver developer has interpenetrated how to use the Linux kernel API for drivers. This is important information so the Linux kernel developers know functions are used and by who. One of the bigger problems Microsoft windows kernel developers have historically admit to is not knowing what functions they are exporting in the so called stable driver API/ABI are in fact used with windows.
The hard point here is for Linux core kernel developers to make the exported functions to drivers decent they need at least reference driver code from driver makers to know what they are using and how they are using it.
Comment