The high level question here is whether there is any technical difficulty that has prompted the separate development, or whether it was mostly logistical. (Since as part of the research I do, I look into large scale variability..) It's not that I don't care about the logistical issues, but if I found the answer were mostly logistical it would show this was a bad example of the thing I wanted to do :-)
On Fri, Mar 22, 2013 at 11:00 AM, hagenp <[email protected]> wrote: > On Wednesday, 20 March 2013 16:13:19 UTC+1, Kristopher Micinski wrote: >> >> I understand the management issue, that's very real, but can you give >> any ideas as to why maintaining a single codebase would be difficult? > > > Distributed development on a single code base is always difficult, even > within the same company. > More so with several - competing! - companies. > > Imagine a kernel-internal structural change that would affect several > architectures. Every single supporter / implementer needs to be "in the > boat", or you will have to support two different versions of your interface > - the old one and the new one - for a considerable time. (Google for "Big > Kernel Lock" to see an example.) > I did kernel development when the big kernel lock existed, but my intuition was that that was just a bad idea to begin with :-).. Even outside of companies, the big kernel lock was a problem because it was a cross cutting kernel feature with a badly designed interface (partially because it meant that you had to use different concurrency facilities, and there was just no easy way to do that). > Then a lot of SoCs contain proprietary technology. E.g. for the PandaBoard > you always need to hunt down the correct EGL2 graphics driver blobs (PowerVR > code from Imagination Technologies Limited) that correctly match your Linux > kernel, or it won't properly boot into the GUI. Yup, that's absolutely a concern. > Assume you do do some development on a multi-architecture kernel, and you > change something. Theoretically, before you can commit your changes, you > need to build and test them for all potentially affected architectures. That > is a LOT of architectures (>1000). In fact, probably nobody can really do > this. (Yes, modularization helps. A lot! Unless e.g. you need to change the > module interface itself.) That's a good point as well. > How do you want to handle these problems for a common code base, spanning > multiple architectures, and affecting lots of different competing hardware > vendors? I'm not proposing a single solution, just looking for current problems. There are multiple proposals to do this: software product lines (static analysis and modular testing has been developed in a composable way), feature oriented programming, aspect oriented programming. Each of these basically treats features as a first class feature of the language. As I said, I'm not proposing this be done to the entire linux kernel: I know that won't work. I'm just looking for motivation for more research. If you are really interested, there has been a good amount of work on type checking and doing static analysis on real configurable software (the linux kernel, in particular). For example, the TypeChef project. > >> >> Because the configurations are different, and include specific mods? > > > Partially. Also it is a business / historic development process issue: > > The quick-and-dirty way of supporting an SoC (or a specific Evaluation > Board, aka "machine") is to start with a kernel that is already roughly > doing what you need, and then to "just" change the things you need to be > done differently. > Hey presto! It works! Now to the next project! > > Or - if you really have the time - you can now do some nifty special > optimizations - so your code runs specifically fast on your platform, giving > you a business advantage. > > This scheme minimizes the time spent by the individual developer to support > her specific SoC or eval board. > Right, this is basically what I've done in the past, and what I assumed was done by vendors at large. > > From a "grand view" perspective, it is of course disastrous: this > development style efficiently prevents that you can ever have a really > "unified" kernel. > > Instead of using an existing, well-maintained kernel driver (module) and > just setting the correct parameters, or of carefully augmenting existing > code and adding a new parameter setting, you just reinvent the wheel again. > And again. > > For the ARM architecture this got so bad, that two years ago Linus Torvalds > himself brought up the issue. > See [http://thread.gmane.org/gmane.linux.kernel/1114495/focus=55060] for the > whole thread. The key mail is also here > [https://lkml.org/lkml/2011/3/30/834]. > Subsequently Linaro was founded to address the problem. (And they seem to > have done marvellous work.) > > For ARM, even the old pre-device-tree system works like this: You can build > a kernel for multiple machines. The boot loader must pass a parameter to it > during boot (a "machine type" number in a register, e.g. R2),. Then the > correct module initialization routine is called for your machine. If the > kernel does not find the passed-in number in its compiled-in list of > supported machine types, it just stays in an endless loop (to avoid doing > any harm). > > Now the ARM kernel branch also moved towards "device trees". Now the boot > loader (e.g. U-Boot) passes a data structure to the kernel that contains > configuration information for the available devices. If you have a new SoC > that only re-uses a lot of peripheral blocks (just with different addresses, > etc.) then you don't need to build a new kernel for it at all: just generate > the "device tree" for it and have the kernel load it on boot. >> >> My idea was that most vendors took kernels, added a few modules, >> changed the configuration, and that was that. > > > In principle this is what they do. But - as stated - don't forget time > pressure on kernels for new devices or SoCs. > There is also a personal factor for the individual developer (wherever s/he > sits - in America, Europe, China or India): > To do "the right thing" takes more time - you need to analyze and understand > an existing driver to be able to carefully extend it. While you analyze and > understand, you don't write code, so your "SLOC count" goes down and you get > less payment, or eventually some nasty questions from your boss about your > efficiency. > If you just copy the whole kernel or driver and twiddle what needs to be > changed, or if you write a simple driver from scratch, this is much faster. > So even large companies fall into that trap. [Example withheld. :-)] > > > As you see, it's not so much a matter of technology, but of business > /development / management interests and knowledge scope. What you want is > possible, already today. Question is: is it feasible? > Is your "buying power" large enough? Then you can likely convince the > hardware vendors to do really good and clean kernel development. > > Otherwise the best you can do is to invest some time and energy and try to > help "cleaning up the mess". If you employ developers on your project, make > it clear to them that "clean integration" is what you actually want. > Thanks for your anecdotes. I was wondering what the most difficult parts of kernel development were, but I'm starting to think that it's just that most people who do kernel development are inexperienced and the economics deincentivize developers from correctly integrating changes. Kris -- -- unsubscribe: [email protected] website: http://groups.google.com/group/android-kernel --- You received this message because you are subscribed to the Google Groups "Android Linux Kernel Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
