On Mon, Mar 25, 2013 at 12:21 PM, hagenp <hagen.pat...@gmail.com> wrote:
> 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.)]
>
Okay, interesting!
>> 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.
>
Not at all, I wasn't trying to say your answer was in any way bad. I
don't expect people to tailor their answer to the needs of my
question, I just wanted to give some rationale as to why I wasn't
hoping for the (perhaps pipedream) of having a truly unified kernel
for all of Android!
>> > 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.
>
Right, that's another good insight.
>>
>> 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?
>
I guess my line of reasoning here goes something like: an experienced
developer knows that making changes the right way (when that person
knows how to make them!) will ultimately save time in maintenance down
the line. But again, maybe this is just an idealistic outlook that's
not properly grounded in reality!
>>
>> 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.
Agreed. I guess the main question in this case is: is there any way
that the code can be structured so that "quick and dirty" becomes less
likely to be disruptful to the entire codebase and cause degeneration
of things. In the case of the kernel in this issue, it seems that
it's more likely that making the right changes takes longer than
taking the easy way out, and people are eager to ship.
Kris
--
--
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.
