Lack of Specifications (was my work...)

Andy Green andy at
Fri Jun 6 10:14:56 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:
| On Fri, 06 Jun 2008 07:35:00 +0100 Andy Green <andy at> babbled:
| Well there is nowhere a spec that says the LED needs to do ANYTHING...
:) so

Actually the guy who specifies our products sent out a mail on an
internal list asking for this functionality, which I unwisely stepped up
to deliver.  I should've just sat on my hands.

| even the LED is superfluous. we should ignore it. (as such i don't see
an mpu
| being needed to do anything with the LED while charging - why? we
don't need to

This pretty nicely makes my point, we should not be arguing at this late
stage about simple device behaviours that should have been specified
from the start.  This is a huge morale suckage that puts us in a place
that actually doing anything that has to make any assertions into any of
the huge undefined spaces invites nothing but armchair opinions about
how it should have been done differently.

| in the end we dont have a spec. we have an existing platform we are
stuck with
| - for better or worse. if anything software should simply adjust to it
and make
| do. don't try and do things the hardware just won't be good at. some
things are
| raw requirements for the hardware, and we just can't ship without it,
| are entirely soft. :)

This is not a way forward.  The lack of adequate marching orders affects
things like the build system as I mentioned that is a pure software
issue already.

In particular when it comes to the next platform, we can participate in
specification formulation but ultimately once that is done, the decision
about MPU or not falls out of the needs of a truly detailed functional
spec, not out of your personal opinion formed some distance from, eg,

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


More information about the openmoko-kernel mailing list