new kernel ... / meaning of stable-tracking

[Andy Green]

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

Somebody in the thread at some point said:

| Hmm yes, what do we do with the ECC ? I see three possibilities:
|
| - change kernel and NAND u-boot, and tell people to use NOR u-boot
|   only to load u-boot into RAM
|
| - idem, but make NAND u-boot auto-detect the ECC algorithm, and
|   tell people to use NOR u-boot for anything but rootfs or kernel
|
| - switch to NAND qi
|
| What do you think ?

Qi lacks any ECC support right now and going forward it looks like we
don't even need NAND support in it.  So we would be adding it just for this.

Holger suggested the auto-detection before and although it's a fudge
actually either that or "do nothing" is probably the best way forward.
It allows people to choose; NOR can only write soft ECC, we should set
NAND U-Boot to write with hard ECC, and the kernel to keep what it finds.

BTW when I tested the current stable-tracking which is 2.6.27-rc5+, I
tried starting a rootfs and jffs2 blew chunks on it.

Ton of these

[21474539.135000] JFFS2 warning: (1) jffs2_sum_scan_sumnode: Summary
node crc error, skipping summary information.

and then bunch of these

[21474539.645000] JFFS2 notice: (1) read_direntry: header CRC failed on
dirent node at 0x2d8f24: read 0x4d35941d, calculated 0x4d35961d

and then

[21474539.780000] Kernel panic - not syncing: Attempted to kill init!

So that kind of thing makes me think about "do nothing" on hard ECC.

|> So I intend to sort that and then propose we shift to 2.6.26.
|
| Perfect ! By the way, now that you mentioned suspend/resume, what's
| the plan with resume dependencies ? Is this something you want to
| propose as mainline functionality ? Or do you expect it to vanish
| in the course of the suspend/resume cleanup ?

All but one IIRC came out in the device tree re-ordering.  So we will
see what is left when that is finished, it could be nothing or maybe we
need it to mop up something horrible.

|> I don't see we need to freeze development.  You can pick a day to take
|> our tree and do the diff, and aim to get that upstream.
|
| Ah, but then you'd have a diverging branch that will take months
| to get merged again, and where lots of changes will happen in the
| branch and in its parent.

That answer came out very smoothly, but I am not sure you quite
understand what the current set of branches are for.

This "cleanup" of 2.6.24 you propose is way backwards IMO.  We need to
leave our current tree alone for that.  You have to do your work at
upstream HEAD and that means stable-tracking branch or a derivative is
where all your action is.  As I explain now the way I see it the results
of this upstream work won't be seen for many months in shipping kernel
and that's a good thing for us.


Currently, we do not take in upstream stuff into shipping kernel except
at long intervals, you can see it is true by the way we are on 2.6.24
and upstream is on 2.6.27-rc5+.  That's OK and how we should go on, for
example by moving to 2.6.26 as we discuss here and then sticking with
that until we jump forward again.  It's why we can call it "stable".

If that was all we were doing, as you know it would be a bad situation,
because we would lose track of upstream changes and be faced with a
"wall of death" at these jumps forward: we both felt that before Harald
helped us out getting from 2.6.22.5 to 2.6.24.

But since then I have not only been constantly rebasing mokopatches
against upstream head in the mokopatches-tracking branch, but rebasing
stable-tracking on top of that and keeping it up to date with our
current stable patchset modified where necessary already for the later
base.  So stable-tracking branch is essentially TODAY'S stable branch
ported to 2.6.27-rc5 right now.  It's "live" both for its upstream base
AND our full patchset.

This is a pretty big freebie for any upstream effort in itself, but
since the meaning of stable-tracking is that it immediately rebases
against upstream unlike our "stable" branch, any patches that you manage
to get in mainline will not only turn up there quickly, but will have to
be resolved against the existing patchset in an ongoing manner.  That's
exactly what stable-tracking does, integrate upstream HEAD with our
patchset.

Over time, we will branch off stable-tracking to make 2.6.27 or 28
branch for our next leap forward, and it is only then that we will see
the stuff that got into mainline coming into our shipping kernels.

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

iEYEARECAAYFAkjT9OYACgkQOjLpvpq7dMpCqwCeIOwCR73+goxHR9cIeSs4B99x
SUoAn1whjWn64AQb+KAR5lWjhe7o9TMu
=leRB
-----END PGP SIGNATURE-----