[PATCH 0/5] Enable Qi / backup rootfs

Werner Almesberger werner at openmoko.org
Fri Aug 22 23:45:55 CEST 2008

Andy Green wrote:
> This is like the third time I ask for that killer scenario where we need
> a change in kernel parameters for normal use

I already gave you one, the kernel log buffer. That's a pretty common
small adjustment that you may also ask users to make to catch the full
story of an intermittent crash they're seeing.

Another example would be transition of something like the ECC algorithm:
1) you implement the new algorithm, add a switch, but leave the old one
   as default
2) developers can now test it in their normal environment
3) if it's good, you recommend switching to the new algorithm
4) people migrate their system at their convenience. When they change
   the algorithm has no impact on whether they have access to other
   new kernel features or fixes.
5) at some point in time, you change the default
6) even later, you throw out the old functionality and remove the
   option (which is then just ignored)

Yet another example would be drivers that need some early or static
configuration. E.g., some USB drivers need to be told about IDs.
For instance, you need to pass those parameters to the FTDI driver
to use our debug board.

In all these cases, you could avoid using a boot parameter. But it's
a standard feature in the Linux kernel that has been around for some
16 years, so both users and developers will expect it to be available,
and you can't count on not eventually running into a situation where
things get painful if it's not readily available.

Besides, what would be the gain of getting rid of it ? Then you'd
just force people to make that configuration change by some other
means, and then you'd have to figure out where else that dreaded
persistent state is hidden.

> that can't be handled in Qi update.

But you don't want to have to update qi. Eventually, we want to treat
it like NOR, i.e., not even advanced users should have to update it.
That way, it can always be relied upon to boot the system.

> Can you provide a link to where I made that "clear"?  Should be easy
> since you state it as a fact.

Heh, I think I can tell by now when we reach the point in a
discussion where you dig in and will defend that position to
the knife ;-)

> ~ And it is clear we should implement a full backup rootfs re-using
> normal packages since we have all the bits and bobs to hand.

Hmm, depends on what you mean by "full". I don't think we really
want to have much of our GUI there, and probably most of the
services won't be terribly useful either.

It's not a question of space or whether we can do it, but just of
keeping things reasonably simple and avoiding to have to deal with
bugs in exotic subsystems. (E.g., if you include GPS in the boot
loader, and it has problems, I think you have to be incredibly
bored to want to debug that ;-)

If you mean "shell and the usual utilities", then I'd agree that
we shouldn't be too stingy, since they're likely to be very well
tested and have reasonably low complexity. I'd even throw in a
very simple GUI, like the Petitboot we've already talked about.

- Werner

More information about the openmoko-kernel mailing list