kernel config & git - (was: [PATCH] Use the pcf50633 APM emulation code...)

[Sean McNeil]

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