Andy,
You are forgetting one thing - the whole beauty of open source is you
are free to do whatever you want with the thing. If users want to create
a full-blown Debian distro for the phone, then more power to them. The
software stack I work with is completely divorced from openembedded and
they are pretty determined to specify YAFFS2 over JFFS2. Having used
both, I have to say JFFS2 is a lot more stable, but takes forever to
boot. The huge boot time was the breaking point in the decision. This
doesn't mean, however, that you should add support for YAFFS2 to your
kernel git.
The relationship between the kernel and application layer of the OM
phone should be minimized. The job of the kernel is to supply all the
necessary hardware support to the application layer with little
exception. One of those exceptions is the defconfig. This should be a
configuration that is appropriate for someone that will use the kernel
with the expected application layer. Other layers like mine will just
have to maintain their own config.
For YAFFS2, there is a separate git source to add it into the kernel.
I'm not sure if it is in the main repository, but OM git shouldn't care.
You don't use it, don't need it, don't have any reason to touch it.
In the long run, I think you are heading in the right direction by
basing your work off a main kernel as opposed to keeping an entire
version. If I understood you right from a previous email the mechanism
should end up looking like:
git clone mainline-kernel
git pull git.openmoko.org/OM-changes
Was this what you had in mind? There could then be branches for a number
of specific versions of linux kernels or the tracking branch. These
branches could in turn be based on some other branch to assist in
merging necessary fixes to all the appropriate branches.
Andy Green wrote:
Somebody in the thread at some point said:
|> I'm going to pass on YAFFS, I looked at it briefly some months ago when
|> we removed it. It just added to our patch load and we don't use it on
|> GTA* so far, and look to be headed in a direction away from it.
|
| Well, I still have the hope that someone takes a shot at evaluating its
| performance on the Neo. To ease that, I have turned this back on in OE.
I also hope users decide to do random things not necessarily based on
what we decide we like (good example is the fully working Debian that
came out of nowhere). But in this case, the future for us is definitely
SD Card based. jffs2 and yaffs are just more complicated
poorly-understood workarounds for the horror that is raw NAND. In the
SD Card world, we treat it just like a HDD, with familiar and stable
ext3, and the capability to always be able to expose it / fix it on
another host. In that sense I think for us jffs2 / yaffs whatever are
going backwards towards "special pleading" embedded status when we are
going forwards towards being a reduced formfactor laptop.
-Andy
