Proposal: "debug" branch for the kernel
jayv at synth.net
Wed Jul 9 12:14:33 CEST 2008
> When I say, "let's have a talk about this auto resume thing and how
> can be leveraged by the various levels", we do not have that
> we have "I have got a C compiler in front of me and I will make a
> right now to 'solve' what I think is the problem".
Yeah, thats 'coz your stacks are all flat. Wouldn't be this way if
you had a single person in charge of making the final distribution-
specific (that means policy, not just technology) decisions about how
best to integrate these various levels in your stack in a way to suit
> It's a way of thinking about it, but I got choked on "the kernel needs
> to do what its told to do by devices", it's as if there is some kind
> ~ concerted effort to neuter the kernel in all aspects.
The kernel is nothing without userspace. Ditto, likewise. The kernel
needs to service the user space applications. Thus, kernel hackers
need to service application developers. In my view, kernel hacking
(while difficult and experty) is a lower-order degree of development
than apps development, and kernel hackers ought to be a little less
smart and a bit more subservient to the application/distribution
people who are trying to put together the final package. Smarts are
one thing; cooperation towards a desired end-distribution package that
rocks is another thing entirely.
This whole suspend and device behaviour issue isn't going to get
solved by kernel guys saying "the only smart way to do this is <blah>"
or by apps guys going "I can write code in 35 seconds to fix it, so
thats what we'll do". Its a distribution problem. Configuration
management, if you will.
Can't you just solve the suspend issue, like its been solved countless
hundreds of times already over the last 30 years, and just treat the
power-change states as init run levels, like you're supposed to?
> ~ By all means lets have a collegial discussion from all of the layers
> mentioned above to try to see that everyone gets what they need, I
> see all the way through that stack and I am very certain that most
> at the other end cannot see all the way down to my end either,
> they'd be a bit more cautious "explaining" how things should be done
If there were a more responsible person taking issue with distribution
policies, then the rest of you guys would fall in line, I think. But
thats just my personal opinion, and it is weighed by the fact that I
think the OpenMoko project, in general, is being (almost disastrously)
hindered for lack of a distribution-policy direction. We *need* to
get the problems solved, but at what layer in your stack cake do we
stick the fork .. this is a broader issue, and thus a distribution-
policy manager would be best suited to do this. Not 'the kernel
hackers/experts', not 'the raster pro', etc. A distribution manager.
More information about the openmoko-kernel