some question about / adding commandline files from rootfs
werner at openmoko.org
Tue Aug 26 17:25:48 CEST 2008
Andy Green wrote:
> solution here is to continue to do that by default and abort that if AUX
> is seen during that time and go directly to backup kernel load.
Okay, let's try this. If the fallback choice is always the same as
the "magic key" choice, there's also no problem if loading the default
fails very rapidly.
> We already have better code than this with the kernel source structs and
> it needs to work with that as I suggested.
Sure, that was just pseudo-code.
> I can't convince people that these commandline addons are not necessary,
> putting them into the rootfs is not the worst way. Although it means
> one less point to kexec...
Rootfs also has the advantage that they travel with their kernel.
E.g., if you had an SD card with a kernel that tries something with
initrd, and your normal card that doesn't, it would be very
inconvenient if you had to change anything else when swapping cards.
> But I don't like the way it still requires management of raw partition
> in NAND case because we can't mount its rootfs. Kernel magic partition
> is bad enough.
Hmm, I don't see any way how we could really avoid having at least
one partition, i.e., the point we say qi is never going to grow
Having access to that partition already means that we need to do the
math for sizing it and we need to have some way to convey the location
of the partition to our tools, be this through the mtdparts parameter
or some other means.
So it doesn't seem too horrible to apply this also a second time.
> NAND is once again the problem child needing more special pleading.
Yeah, we can't escape it completely, try as we might. It's getting
much better, though.
> We could reduce the size of GTA03 backup rootfs and
> go for mounting it jffs2 in Qi, then we unify the kernel location for
> NAND too into being inside rootfs.
Heh, nice one :-) But are you sure you want to wrestle with JFFS2 ?
I thought you hated it too ;-)
> GTA02 could follow all this really too and become SD-centric.
That would be nice, yes. I think you've pretty much switched to an
SD-centric mode of operation already a while ago, haven't you ?
Does the system feel responsive enough ?
> What happens if he put a bad thing in this commandline file...
Just the same as putting a bad kernel. Of course, our users better
don't do that NAND kernel and command line upgrade while they're
having an emergency with their SD card(s) as well.
> it seems clear that backup kernel itself should not have user modifiable
> commandline used to start it, there really is no reason for it anyway.
Why create a special case where they have to supply the command
line at build time ? That kernel shouldn't even be special, so if
the command line is separate, you could just drop in a new one
from our daily build, and never even think about the command line.
More information about the openmoko-kernel