Proposal: "debug" branch for the kernel

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:

|> | There really needs to be some leadership resolve on these issues - we
|> | can't have the kernel hacking going on with no clear over-all
|> | distribution guidance.  I've read this thread with trepidation lately.
|>
|> Welcome to the FOSS world.
|
| Duh, I've been in the FOSS world since the 80's.  This ain't news.

Kernel hacking can and does happen without "clear overall distribution
guidance".  For example the recent work to make suspend and resume
faster and cleaner does not need any help there except in small questions.

I agree that a holistic view is hard to come by, but it's hard to come
by for real reasons, the whole "stack" from:

~ - fine hardware decisions through
~ - firmware through
~ - kernel driver through
~ - through kernel APIs through
~ - userspace then on through
~ - libs, through
~ - daemons, through
~ - X, through
~ - widget libs, through
~ - protocol stacks, through
~ - application stacks

is not truly understood by one person.  Each of us has a subset of these
that we can actually make reasonable decisions about because we are
properly informed, then we have some experience with others and others
are a closed book.

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".

|> | The whole issue of the state of devices during suspend/resume *is* a
|> | kernel issue, and it *is* a user space issue.  The kernel needs to do
|> | what its told to do by devices, and the state of these devices
|>
|> What?
|
| Suspend is a run-level.  Resume is a run-level.  Yes, even a power-down
| of a component is a matter of run-level state change.

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 critical infrastructure to keep userspace away from device
detail, the friendly geek in there that knows how to get stuff done: it
needs to do its job without guys used to X drivers mmaping registers and
so doing kernel stuff in userspace doing what they alone think is best.
~ 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.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkh0gxYACgkQOjLpvpq7dMoXjgCgh+SvtFlF4F2h+wlRNdfd7IPk
D+MAn2ycIHxulZky4GJvukobzkyxT9ym
=MUH6
-----END PGP SIGNATURE-----