some question about / adding commandline files from rootfs

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| 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.

No need to "try" it, it will definitely solve this issue cleanly.
Instead of loading the full kernel size in one call, Xiangfu can make a
while() loop there loading 64KByte units for example, and inside the
loop we check for AUX press.  If seen we always abort the loop and jump
to the last kernel source for the board, which is the backup one (and no
longer look for AUX).

|> 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.

Agreed, what warmed me to it though is it gives the determinism back
just from nuking rootfs on SD card.  That's probably good enough that we
drew the sting.  But for NAND -->

|> 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
| beyond.

No I meant after this pleasing talk of unification of kernel and
commandline file under single rootfs, NAND leads to us having to handle
raw type partitions for kernel and commandline separate from the rootfs.
~ Qi itself is mandated to be a raw partition by steppingstone action so
there is really nothing to do there.

|> 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 ;-)

I just see it as more special pleading for NAND, it is "unusual file
system".  But, large NAND is currently a fact and then it means we ought
to have fs for it that does wear levelling.  By default that is going to
be jffs2.

|> 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 ?

All I can say is it feels the same, although I think Glamo MMC is
actually slower than NAND a bit.  Many other users now are booting SD
for Debian and other rootfs and I didn't notice complaints about insane
speed loss.  So I think it is OK for customers.

|> 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.

Huh?  No Qi sythesizes a commandline anyway based on board and kernel
source, so there's no special case.  The synthesized commandline will
continue to be what you get in the absence of the rootfs commandline
file, and I expect we will not create a commandline file by default even.

What I meant is that we do not want function of backup system to have
dependency to anything it doesn't have to... there's zero legitimate
case for end user to touch backup kernel commandline.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEUEARECAAYFAki0JXYACgkQOjLpvpq7dMpoJwCfZAODS9l7eBtS1VXtok5YqZ8D
1rYAmJI2HKI2ccCogEs9UY2IClz+a+Y=
=lzbD
-----END PGP SIGNATURE-----