On Thu, May 29, 2008 at 12:59 AM, Charles Manning <manningc2@xxxxxxxxxxxxx> wrote: > Hi > > I'm the author of YAFFS. This is not in the kernel tree, but is fairly easy to > integrate by just pulling a tarball and running patch-in script. > > I am curious as to whether people consider the current mechanism "good enough" > or whether it is worth the effort trying to get YAFFS into the kernel tree. > > Pros I can see: > * In tree means better testing (maybe). > * Keeping current with kernel API changes. > > Cons: > * More effort for YAFFS maintainers (me mostly). > * Effort getting code into kernel coding style (unless I can get a waiver on > this). > > Thoughts?? We at protei (protei.ru) are using yaffs for over a year now, switched from jffs2, mostly because of the huge mount time difference. Have yet to see any serious problems. The process of patching the kernel with yaffs is quite smooth, but you loose the ability to track the changes made in yaffs. We've got a git kernel tree, to which we add our stuff, and also periodically repatch it with a fresh yaffs. The problem is, all you can see later is a commit labelled "A Yaffs update", revealing little details on the contents. Not cool. If anything, I'd ask for merging this files sytem rather sooner than later, as it should be useful for many embedded developers and touches nothing outside the fs/yaffs2 directory. The only thing that bothers me, is the licensing. Currently is seems like Apleph1 is selling license exceptions for yaffs. Either this should become impossible after yaffs gets any commits from the community, or you will have to maintain a separate version without such commits. > -- CHarles > -- And thank you for working on yaffs and being positive about merging it into the mainline kernel. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
