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
