YAFFS in the kernel tree?

YAFFS in the kernel tree?

[Charles Manning]

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??

-- CHarles
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: YAFFS in the kernel tree?

[Robert P. J. Day]

On Thu, 29 May 2008, Charles Manning 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??

perhaps a dumb question, but does this include YAFFS2 as well?

rday

p.s.  and, no, you don't get a pass on coding style, but others will
almost certainly help you out there. :-)

--

========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.

http://crashcourse.ca                          Waterloo, Ontario, CANADA
========================================================================
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: YAFFS in the kernel tree?

[Charles Manning]

On Thursday 29 May 2008 09:12:40 Robert P. J. Day wrote:
> On Thu, 29 May 2008, Charles Manning 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??
>
> perhaps a dumb question, but does this include YAFFS2 as well?
>

> p.s.  and, no, you don't get a pass on coding style, but others will
> almost certainly help you out there. :-)

That would only be yaffs2 which has yaffs1 backward compatibility built in.

-- CHarles

--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: YAFFS in the kernel tree?

[David Woodhouse]

On Thu, 2008-05-29 at 08:59 +1200, Charles Manning wrote:
> 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.

I've never paid close attention to YAFFS, and part of the reason for
that is that it's never been considered good enough to be merged into
the kernel tree. If it isn't even being posted for _review_, then it
might as well not exist.

There's a lot more to code review than the cosmetics of 'coding style'.

I would definitely encourage you to get the code into a shape where we
can consider merging it.

-- 
dwmw2

--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: YAFFS in the kernel tree?

[Robert P. J. Day]

On Thu, 29 May 2008, Charles Manning wrote:

> That would only be yaffs2 which has yaffs1 backward compatibility
> built in.

first things first -- make it available somewhere we can peruse it.
that would be a start.

rday
--

========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.

http://crashcourse.ca                          Waterloo, Ontario, CANADA
========================================================================
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: YAFFS in the kernel tree?

[Mike Frysinger]

On Wed, May 28, 2008 at 4:59 PM, Charles Manning wrote:
> 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).

i'm pretty sure you're going to have to cull all of the
LINUX_VERSION_CODE checks.  that means the in tree yaffs code is only
going to track mainline kernel versions.  i dont know whether you
consider that a pro or con (i say it's a pro), but if you want/need
those checks, you're basically going to have to maintain two forked
versions ...
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: YAFFS in the kernel tree?

[Charles Manning]

On Thursday 29 May 2008 09:24:14 Mike Frysinger wrote:
> On Wed, May 28, 2008 at 4:59 PM, Charles Manning wrote:
> > 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).
>
> i'm pretty sure you're going to have to cull all of the
> LINUX_VERSION_CODE checks.  that means the in tree yaffs code is only
> going to track mainline kernel versions.  i dont know whether you
> consider that a pro or con (i say it's a pro), but if you want/need
> those checks, you're basically going to have to maintain two forked
> versions ...
> -mike

The main reason for those version checks is that YAFFS tries to acknowledge 
that not everyone just uses the latest kernel. Many embedded developers are 
using older kernels (for various valid reasons) (though this practice is 
probably on the decline) and I would like to continue supporting that.

I would expect that this would make for two versions of yaffs_fs.c: the CVS 
one for all comers and the in-tree version which is cleaned.

-- CHarles


--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: YAFFS in the kernel tree?

[Mike Frysinger]

On Wed, May 28, 2008 at 5:34 PM, Charles Manning wrote:
> On Thursday 29 May 2008 09:24:14 Mike Frysinger wrote:
>> On Wed, May 28, 2008 at 4:59 PM, Charles Manning wrote:
>> > 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).
>>
>> i'm pretty sure you're going to have to cull all of the
>> LINUX_VERSION_CODE checks.  that means the in tree yaffs code is only
>> going to track mainline kernel versions.  i dont know whether you
>> consider that a pro or con (i say it's a pro), but if you want/need
>> those checks, you're basically going to have to maintain two forked
>> versions ...
>
> The main reason for those version checks is that YAFFS tries to acknowledge
> that not everyone just uses the latest kernel.

i know

> Many embedded developers are
> using older kernels (for various valid reasons)

and for plenty of invalid reasons ;)

> (though this practice is probably on the decline)

i hope so

> I would like to continue supporting that.

honestly, this is the only bit that matters ... if someone wants to
run an older kernel but you're only interested in maintaining
mainline, then those people be damned.  stop using older kernels.

> I would expect that this would make for two versions of yaffs_fs.c: the CVS
> one for all comers and the in-tree version which is cleaned.

as long as you're completely aware and OK with the situation, then
let's stop talking about proposing for inclusion and post for review
already

wrt coding style, ive seen plenty of proposed things that were much
worse ... i dont think it'd take too much work to fix it ... you
should start with:
sed -i 's:[[:space:]]*$::' fs/yaffs*/*.c
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: YAFFS in the kernel tree?

[David Woodhouse]

On Thu, 2008-05-29 at 09:34 +1200, Charles Manning wrote:
> The main reason for those version checks is that YAFFS tries to acknowledge 
> that not everyone just uses the latest kernel. Many embedded developers are 
> using older kernels (for various valid reasons) 

The only vaguely valid reason I've ever heard is that they've already
been through QA and are shipping a product based on the old kernel, and
now they need some minor bug fixes. Even for a more serious product
update adding new features, it should be able to switch to a newer
kernel unless you've made some horrendous mistakes in the original
deployment, like not getting everything you use merged upstream.

And still -- if they choose to use an ancient and known-broken version
of the rest of the kernel, why would they want to combine that with the
newest, shiniest version of YAFFS? It just doesn't make sense.

I used to keep JFFS2 building for older kernels; I don't for a moment
regret abandoning that effort. Far from being helpful, I actually think
it was counter-productive, because it made people think that was a
_sane_ thing for them to be doing. It just isn't.

> I would expect that this would make for two versions of yaffs_fs.c:
> the CVS one for all comers and the in-tree version which is cleaned.

It's not even that hard to maintain those in parallel with a modern
version control system like git, pulling changes from one tree to the
other. We export JFFS2 for use in eCos that way.

-- 
dwmw2

--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: YAFFS in the kernel tree?

[Alexey Zaytsev]

On Thu, May 29, 2008 at 12:59 AM, Charles Manning
<manningc2-jEEI2ySEPisjAXWc8ALWsQ@public.gmane.org> 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: YAFFS in the kernel tree?

[James Chapman]

Charles Manning wrote:
> On Thursday 29 May 2008 09:24:14 Mike Frysinger wrote:
>> On Wed, May 28, 2008 at 4:59 PM, Charles Manning wrote:
>>> 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).
>> i'm pretty sure you're going to have to cull all of the
>> LINUX_VERSION_CODE checks.  that means the in tree yaffs code is only
>> going to track mainline kernel versions.  i dont know whether you
>> consider that a pro or con (i say it's a pro), but if you want/need
>> those checks, you're basically going to have to maintain two forked
>> versions ...
>> -mike
> 
> The main reason for those version checks is that YAFFS tries to acknowledge 
> that not everyone just uses the latest kernel. Many embedded developers are 
> using older kernels (for various valid reasons) (though this practice is 
> probably on the decline) and I would like to continue supporting that.
> 
> I would expect that this would make for two versions of yaffs_fs.c: the CVS 
> one for all comers and the in-tree version which is cleaned.

Submitting code into the kernel doesn't mean you have to maintain both 
in-tree and out-of-tree versions. Once the code is accepted into the 
tree, I suggest that all subsequent development is done on the in-tree 
version. Leave the CVS version for people who run older kernels - don't 
try to keep the two in step. If users of older kernels want a new 
feature or bugfix from the in-tree version, let them backport it; they 
probably do so routinely already for other kernel components anyway.

I maintained some kernel code out of tree for a while. In my experience, 
once code is accepted in the mainline kernel tree, the effort in 
supporting and maintaining it dropped dramatically. It can take a lot of 
work to get it accepted but the effort is well worth it if you're 
successful.

I say yes, work on submitting yaffs. :)

-- 
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development

--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: YAFFS in the kernel tree?

[Paul Gortmaker]

On Wed, May 28, 2008 at 4:59 PM, Charles Manning
<manningc2-jEEI2ySEPisjAXWc8ALWsQ@public.gmane.org> 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.

 * exposes your code to folks who otherwise might not be
aware it even exists.

>
> Cons:
> * More effort for YAFFS maintainers (me mostly).

It may look like this is the case initially, but really it becomes a case of
less effort for maintainers (you), once you get over the initial blip/hump of
knocking things into shape and getting it merged.  If you are out of tree,
you have to be aware of all the API changes and subtle dependencies that
may lurk from a side effect of some other changeset.  If you are in-tree and
Al Viro discovers some wide-sweeping bug, he will most likely fix your stuff
for you before you were even aware there was a problem....   :-)

> * Effort getting code into kernel coding style (unless I can get a waiver on
> this).

No get out of jail free card here, for anyone.  Sorry.

Paul.


>
> Thoughts??
>
> -- CHarles
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: YAFFS in the kernel tree?

[Detlev Zundel]

"Alexey Zaytsev" <alexey.zaytsev@gmail.com> writes:

> On Thu, May 29, 2008 at 12:59 AM, Charles Manning
> <manningc2@actrix.gen.nz> 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.

Sorry for jumping in here late, but git should be pretty good about
finding differences itself.  If you can revers-apply the previous
version patch, then apply the current version and git commit, it should
yield much more useful information.

Cheers
  Detlev

-- 
The proprietary-Unix players proved so ponderous, so blind, and so inept at
marketing that Microsoft was able to grab away a large part of their market
with the shockingly inferior technology of its Windows operating system.
                   -- "A Brief History of Hackerdom" by Eric Steven Raymond
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de

Re: YAFFS in the kernel tree?

[Jörn Engel]

On Sun, 8 June 2008 13:45:18 +0200, Detlev Zundel wrote:
> 
> Sorry for jumping in here late, but git should be pretty good about
> finding differences itself.  If you can revers-apply the previous
> version patch, then apply the current version and git commit, it should
> yield much more useful information.

Doesn't work too well, if the git version is different from the
out-of-tree version, because of something like version checks.

What might work is to keep developing the git tree, extract a patch from
that, have a second patch with version checks, etc. and combinediff
those two.

Jörn

-- 
Fancy algorithms are slow when n is small, and n is usually small.
Fancy algorithms have big constants. Until you know that n is
frequently going to be big, don't get fancy.
-- Rob Pike
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html