Proposal: "debug" branch for the kernel

[Jay Vaughan]

> When I say, "let's have a talk about this auto resume thing and how  
> that
> can be leveraged by the various levels", we do not have that  
> discussion,
> we have "I have got a C compiler in front of me and I will make a  
> daemon
> 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  
the user.

> 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  
> of
> ~ 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  
> can't
> see all the way through that stack and I am very certain that most  
> guys
> at the other end cannot see all the way down to my end either,  
> otherwise
> they'd be a bit more cautious "explaining" how things should be done  
> there.


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.


;
--
Jay Vaughan