andy at openmoko.com
Thu Jun 19 17:17:52 CEST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
| Am Donnerstag 19 Juni 2008 14:46:25 schrieb Andy Green:
|> Wow I wonder what else I can do with this super power I have for
|> catalysing sudden activity from the rest of the company when I touch a
|> problem that has lain dormant for months.
| Don't be sarcastic [unless you need it to stay on track]. No one else
| cared until now and I'm superhappy you are tackling all that stuff.
My power is apparently real enough yesterday and today that it isn't
sarcasm to describe it.
| It's just that if you're working on it anyways, you might as well make it
| acceptable upstream.
Well, often that is true and using what is already there makes it an
easier and better solution too, since the stuff in the kernel is usually
pretty much best of breed.
In this particular case the impact of sticking it in userspace for
everything will depend on the speed we run the ADC at, and that will
depend on how much aggregation of the samples we need to do to get solid
results, and that will depend on the algorithm used to filter it. So
we'll be guided about what to do by a beauty contest in power and
performance. That's pretty non-dogmatic, right?
I don't have a problem with going against upstream any time it suits our
goals for the product, or even just gets us a solution so we can go on
(and clean it later if it can be cleaned).
But yes, if it can easily be made compatible with upstream, there's time
and it's worth the engineering, it often means we made better code as a
side effect in my experience.
That said I am working on a very dirty patch right now.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the openmoko-kernel