On Friday, 22 March 2013 19:17:24 UTC+1, Kristopher Micinski wrote:
>
> I did kernel development when the big kernel lock existed, but my
> intuition was that that was just a bad idea to begin with :-).. [...]
>
My point was to look at the *migration* process from BKL to the current
structure. (And how long that took.)
> I'm not proposing a single solution, just looking for current problems.
>
Mhm. Your original question was
I understand that Android maintains a different version of the kernel for
> each specific platform.
> I was wondering why this is the case, and why the code isn't simply
> offered as a single kernel with a
> configuration set for relevant devices?
> Is it simply that modifying the kernel's build system is a pain, or is
> there some deeper programming problem?
>
...and I tried to show a few reasons why things are as they are. Sorry if
I spun away from the core.
BTW. my own very small amount of experience with the kernel comes from some
work to consolidate Linux kernels and an Android root file systems for the
demonstration platforms we need in-house (all ARM-based). I hoped to be
able to re-use a single kernel and root file system for all of them.
Part of the work involved porting platform-specific changes from an older
kernel version to the slightly newer one used for the other two platforms.
Not pretty, it took me quite some time, but I learned a lot.
[We basically froze the trial when we learned that the platform-specific
graphics acceleration for Panda required too many incompatible changes. (A
variant based on a pure framebuffer would probably be possible. But slow.)]
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.
>
Yes, a lot of useful methodologies exist. Very interesting stuff for
academic research.
For me the litmus test is: is something usable by real-world companies for
developing real-world products?
It will be much easier to promote a solution that gives companies a
"competitive advantage", than a solution that is academically "the right
thing to do", but has negative impact for the current bread-winning project.
Maybe my focus s too much on application than on purely academic research.
Sorry.
> 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.
>
Any ideas how to change this? Because that's what is urgently needed. I
hope someone will find a solution.
Linus' intervention has moved a lot in the ARM space. Maybe the codebase
maintainers just need a "code of conduct" or something. The problem I see
is that companies need to develop as fast as possible, but the kernel
maintainers need everything to keep as clean and maintainable as possible.
These are conflicting goals.
> I was wondering what the most difficult parts of kernel development were,
>
...for me these parts are the human factor, i.e. try and move people "to do
the right thing". :-)
but I'm starting to think that it's just that most people who do kernel
> development are inexperienced
>
...hopefully not. OK, there will always be newbies who want to call
themselves "kernel hacker", but usually they don't stay long in kernel
development - too much work, too little to show off.
Or what do your refer to? "Inexperienced" for their specific SoC structure?
"Inexperienced" in the newest {buzzword*} technologies? "Inexperienced" in
kernel development as a whole?
> and the economics [punish developers for] correctly integrating changes.
>
..yup! Even a seasoned developer can be forced to do a "quick-and-dirty"
implementation in order to meet a product deadline. To keep the company in
business. Or just to keep being employed and feed her family.
Good luck! -H
--
--
unsubscribe: android-kernel+unsubscr...@googlegroups.com
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 android-kernel+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
