4 ms·
Not necessarily GPL violations (there are cases of those too, but the bulk of it is not). It's just a matter of nobody having cleaned up the drivers enough to g
by ojn 12y ago
Not necessarily GPL violations (there are cases of those too, but the bulk of it is not). It's just a matter of nobody having cleaned up the drivers enough to get them submitted for upstream inclusion. It can be quite a bit of work to do, and the next generation of product is sitting there waiting on the same people to make that work instead.
You can usually download and diff the source tarballs. Some vendors keep git repos so you can see changelogs as well. There's usually a lot of noise in there though, lots of various imported vendor drivers that duplicate things, firmware files in hexdump format, etc. It's pretty common to see diffs of millions of lines.
- tonyg 12y agoThanks. The noise issue sounds pretty frustrating.
- sandGorgon 12y agocould you elaborate on what you mean by "cleaning the drivers" ? I'm really curious, because it seems that Android has built an architecture where vendor supplied drivers (binary blobs?) can be dropped in without too much changes. But upstream linux needs a considerable amount of rework to "absorb" a driver. Is this deliberate (the same reason why GCC is obfuscated) or is there a technical reason behind it ? Because Android Linux works on thousands of different platforms with a lot of stability - I'm beginning to think that the Android driver model is superior... and perhaps mainstream Linux would do well to move to that.
- mcpherrinm 12y agoI work on an embedded Linux device. Sometimes, we do whatever nasty hack we need to make this kernel work on that device -- but those changes aren't portable, aren't maintainable, and don't meet the quality requirements to be in the upstream tree. There can also be a perception it's "a waste of time" since "nobody will run another kernel on this anyways"