On Wednesday 13 July 2005 03:49, marty wrote:
> I've taken a look at Coywolf Qi Hunt's patch and I think it's fine,
> but it's not really what we need here, becasue it contains
> a very large number of whitespace changes and a small number of
> bug fixes, it's not quiet up to date with the YAFFS2 cvs tree,
> and it is difficult to compare the two because of all the
> white space changes.  (I believe that Coywolf is going in
> the right direction for kernel acceptance, but it's too large
> a step to take at once, for us.)

I have had a look at both Marty and Coywolf's patching schemes and think that 
both have there place, as they serve different roles.

Marty's approach is based on the YAFFS1 patchin I did (but didn't get exactly 
right) which was, in turn based on the mtd patchin scheme.

Coywolf's approach is a "big kernel patch" that gets applied to a kernel tree.

The patchin approach keeps YAFFS2 as a separate tree and applies a few 
symlinks and minimal changes to the kernel tree to incorporate yaffs. This 
means that it is rather simple to manage yaffs separately from the rest of 
the tree. To update yaffs, just pull the latest yaffs code and run the 
patchin. No headaches as to which version of the kernel you're patching 
against etc.

The "big kernel patch" is a nice way to submit a version of YAFFS2 to the 
kernel so that it can be included in the kernel sources. The hassle with this 
is that it means synchronising releases of YAFFS2 with kernel releases.

Once YAFFS2 is in the kernel, I don't think there will be much call for "big 
kernel patches" - except to regularly generate a patchset for the next kernel 
release. Like mtd you'd either use what is in the kernel or pull the code 
from cvs or a tarball and use a patchin.

I think real YAFFS users will pull CVS and use the patchin anyway, since the 
kernel will not include yaffs tools, extra documentation, bootloader code 
etc.

The two approaches don't compete, but rather complement eachother.

-- Charles