* Re: yaffs2 NAND fs
2010-03-02 13:51 ` Arnd Bergmann
@ 2010-03-03 15:09 ` Maxin John
2010-03-04 0:20 ` Mike Frysinger
2010-03-04 12:34 ` Wookey
1 sibling, 1 reply; 6+ messages in thread
From: Maxin John @ 2010-03-03 15:09 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Peter Paul, linux-kernel
Hi,
On Tue, Mar 2, 2010 at 7:21 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 02 March 2010, Peter Paul wrote:
>> I was wondering why the yaffs2 file system has not gone for mainline
>> yet. It's rather popular flash file system in the embedded world, while
>> it is rather easy to patch a kernel to have yaffs2 support [1] it would
>> be even nicer if it was just in mainline.
>> The source of the GPLv2 file system can be found at [2]
>>
>> [1] http://www.yaffs.net/howto-incorporate-yaffs
>> [2] http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/yaffs2/
>
> I would guess it's a combination of multiple reasons:
>
> 1. It has not been submitted for upstream inclusion, at least not
> during the last few years.
> 2. We don't have a staging area like drivers/staging for file systems
> in the way that we have for drivers
> 3. There is now ubifs and (soon) logfs upstream, both of which appear
> to be superior to yaffs in many ways.
This means there should be no reference to YAFFS2 in the upstream
kernel? Because, I have located some defconfigs in upstream kernel
where YAFFS2 support is enabled by default.
ie:
CONFIG_YAFFS_YAFFS2=y
CONFIG_YAFFS_AUTO_YAFFS2=y
in below listed files:
1. arch/arm/configs/msm_defconfig
2. arch/blackfin/configs/IP0X_defconfig
3. arch/blackfin/configs/SRV1_defconfig
4. arch/blackfin/configs/BlackStamp_defconfig
5. arch/blackfin/configs/BF533-EZKIT_defconfig
6. arch/arm/configs/cam60_defconfig
7. arch/blackfin/configs/BF538-EZKIT_defconfig
8. arch/blackfin/configs/BF533-STAMP_defconfig
9. arch/blackfin/configs/PNAV-10_defconfig
10. arch/blackfin/configs/BF537-STAMP_defconfig
11. arch/blackfin/configs/BF526-EZBRD_defconfig
12. arch/blackfin/configs/BF527-EZKIT_defconfig,
Please let me know your opinion on this.
Best Regards,
Maxin B. John
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: yaffs2 NAND fs
2010-03-02 13:51 ` Arnd Bergmann
2010-03-03 15:09 ` Maxin John
@ 2010-03-04 12:34 ` Wookey
2010-03-04 13:43 ` Arnd Bergmann
1 sibling, 1 reply; 6+ messages in thread
From: Wookey @ 2010-03-04 12:34 UTC (permalink / raw)
To: linux-kernel
[Please keep me cc:ed - I'm not on this list]
Arnd bergmann wrote:
> On Tuesday 02 March 2010, Peter Paul wrote:
> > I was wondering why the yaffs2 file system has not gone for mainline
> > yet.
>
> I would guess it's a combination of multiple reasons:
>
> 1. It has not been submitted for upstream inclusion, at least not
> during the last few years.
> 2. We don't have a staging area like drivers/staging for file systems
> in the way that we have for drivers
> 3. There is now ubifs and (soon) logfs upstream, both of which appear
> to be superior to yaffs in many ways.
As someone who has been involved with YAFFS from the beginning I can
give you the reasons (not that they are particularly good ones).
It's about 70%-80% simple inability to keep up with kernel
development, combined with a certain amount of lack of enthusiasm by
some developers and a certain amount of pushback from the MTD people.
Every time we get it vaguely up to date, the kernel has moved on again
before we get round to submitting it. This is of course a reason for
getting it in, not keeping it out, as I am painfully aware, but you
have to get over that effort hump at least once, and we haven't
managed it yet (in nearly 7 years! - oh the embarassment). The closest
we got was about a year ago when I was publically harrangued by Mr
Woodhouse at CELF on exactly this point so I did actually take the
sources and take out all the crap we keep for compatibility with old
kernel versions and checked that the results worked, and removed miles
of trainling whitespace. Then I started going through the list of
things necessary before patches should be submitted but didn't manage
to finish and actually post it for review before something else became
more urgent for a bit. I got to the bit about not dropping single huge
entire-filesystem patches if possible, and foolishly considered if it
could be split up at all. I concluded that it couldn't (or at least I
couldn't), but whilst I'd dithered there was a new kernel out so now I
was too late again and it stalled till now.
YAFFS is in the process of moving to git, which will make it easier to
maintain a 'mainlinable' branch so we can have another go at this
process.
On more ancient history there was not much enthusiasm for mainline
when YAFFS started. The author didn't feel it was ready and the fact
that it is designed, and supported, for numerous OSes, not just Linux,
and our deliberate support of old kernels, meant it contained a lot of
non-current-linux cruft which of course is not appropriate in
mainline.
Later we did want to put it in, but struggled to keep up and get it in
a suitable state, and then things in MTD world changed (2006ish?) such
that filesystems that actively used the OOB area were frowned upon and
we got the strong impression it wouldn't be accepted anyway. So then
there was a long pause until YAFFS gained the ability to run without
using the OOB ('in-band tags'). That happened sometime in 2008, hence
my failed effort in 2009 to try and get this sorted.
So, I agree YAFFS should be in mainline (as someone who has to patch
it into my kernels on a daily basis this would make my life much
easier too). I don't know if it is really 'too late' in terms of the
existence of UBIFS and LOGFS. I don't think so - YAFFS is a
sufficicently different approach that I reckon it still makes sense
for plenty of people, but I guess that's something to debate.
I suppose the thing I stalled on before doing this last time was 'What
is the best approach for getting a great big dollop of a filesystem
like this reviewed'? I was relunctant to send in one 250K patch, but
couldn't really see a better way, and if doing that, it probably
needed quite a detailed supporting explanation. The other thing that
kept me from doing it was that I knew there would be a pile of changes
requested and there was no point kicking off the process unless I knew
I'd be able to devote so time to it afterwards to deal with comments.
Problem is, that never seems to occur.
So, I guess this is another kick. I'll update the mainline patch I
have (which is essentially just YAFFS2 with all the "#ifdef kernel
nnn" code taken out, and the YAFFS-direct and ecos and WinCE code
removed, to current kernel (which also means updating balloon3 to current
kernel so I can actually test it). I'll put that in git and ask people
to take a look. Detailed suggestions on what extra info is needed or
changes made would be very helpful.
Unless of course there is already concensus that this is a waste of
time and Peter and I are the only people that want to see it in
mainline?
Wookey
--
Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian
http://wookware.org/
^ permalink raw reply [flat|nested] 6+ messages in thread