[PATCH 0/5] Enable Qi / avoiding re-introducing "hidden variable"
andy at openmoko.com
Fri Aug 22 13:47:34 CEST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
| Andy Green wrote:
|> The fact they aren't afraid of it isn't really telling us it is
|> "generally useful for production device" though.
| Are we targetting the fetters and shackles faction now ? I thought
| they were happy enough with the iPhone ;-)
People can do what they like with our open software. For our purposes
though, we choose to do with it what suits our needs in production and
dealing with problem reports.
|> It leaves open
|> different kernels and so on, but we can nuke them too and then our
|> situation is deterministic.
| Same applies for the boot parameter line. Call it /boot/uImage.param
| if you want, then you can rm /boot/uImage.*
It's got some truth in it now. In the dynparts world in U-Boot
environment, that was not actually true and you could not easily
untangle board-specific env settings from user choices and share the env
images. It doesn't work that neatly in NAND though, it's just more
complexity and I still didn't hear the case where we can't do without
it. So far it feels a little bit like we want to add user controllable
commandline because it is a feature we saw on other bootloaders.
|> Obviously there is no technical difficulty to do it for NAND or SD. I
|> am trying to avoid the whole class of behaviour-changing variable hidden
|> in the device though.
| It's exactly as much hidden or not as the kernel proper.
It's still another place where behaviour-affecting stuff can hide.
Consider settings are made for commandline appropriate for one kernel
and then the kernel changes.
We seem to be doing OK so far with a canned approach based on boot
source. I am listening for the description of where that falls down but
I didn't hear it yet, just about how we can implement it.
| So when we move GPIOs around in the future, you don't need to
| add yet another board variant to qi, only because something has
| changed that qi doesn't care about anyway.
Board variants are really cheap in Qi, and probably we want to logically
track each board revision that went as far as change GPIO semantics anyway.
-----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