Mike's actual problem / Lorn's actual problem

Andy Green andy at openmoko.com
Thu Aug 7 00:59:25 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:

|> However once we properly protect modules against being used by a
|> different kernel, as I propose and would like to see happen, Mike and
|> others will be unable to ad-hoc issue third party binary kernels as
|> before due to all the extra modules being missing.
| Why are you going to do that?

Doing what?  Not allowing modules from another kernel to be used with
the wrong monolithic image?

Encourage people to create their own kernels on an even footing with us?

Both sound like good things to be doing.

| Mike would not have to create his own kernel+patches if things he fixes
| were getting fixed in the mainline openmoko kernel.

That's a separate issue, but thanks for muddying the waters with it.
Most every patch that gets on the kernel list gets into our kernel or
U-Boot in fact.

Mike's fixes I do want came wrapped up with a ton of debugging patches I
don't want, and I explained why we didn't take them as currently formed
at the time:


Hey Lorn, I just got through reading back on the thread from a week or
so ago where you explain to Holger why some of his patches are good for
you and some aren't.  Well, same here.  I offered to spend time
separating out the functional parts from the invasive debug parts of
Mike's patches, but Mike said he would do it.  When he does, they'll get
smiled upon if at all possible.  But, I don't want to carry the spy
stuff in our stable kernel.

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


More information about the devel mailing list