linux-embedded.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Mike Frysinger" <vapier.adi-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Charles Manning <manningc2-jEEI2ySEPisjAXWc8ALWsQ@public.gmane.org>
Cc: linux-embedded-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: YAFFS in the kernel tree?
Date: Wed, 28 May 2008 17:48:02 -0400	[thread overview]
Message-ID: <8bd0f97a0805281448t1860e9abwacafb27e363dfcfb@mail.gmail.com> (raw)
In-Reply-To: <200805290934.28232.manningc2-jEEI2ySEPisjAXWc8ALWsQ@public.gmane.org>

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

  parent reply	other threads:[~2008-05-28 21:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-28 20:59 YAFFS in the kernel tree? Charles Manning
     [not found] ` <200805290859.54396.manningc2-jEEI2ySEPisjAXWc8ALWsQ@public.gmane.org>
2008-05-28 21:12   ` Robert P. J. Day
     [not found]     ` <alpine.LFD.1.10.0805281711370.3803-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2008-05-28 21:14       ` Charles Manning
     [not found]         ` <200805290914.51814.manningc2-jEEI2ySEPisjAXWc8ALWsQ@public.gmane.org>
2008-05-28 21:16           ` Robert P. J. Day
2008-05-28 21:15   ` David Woodhouse
2008-05-28 21:24   ` Mike Frysinger
     [not found]     ` <8bd0f97a0805281424g2ceae455x774e8d66aba4ec2b-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-05-28 21:34       ` Charles Manning
     [not found]         ` <200805290934.28232.manningc2-jEEI2ySEPisjAXWc8ALWsQ@public.gmane.org>
2008-05-28 21:48           ` Mike Frysinger [this message]
2008-05-28 22:00           ` David Woodhouse
2008-05-28 22:40           ` James Chapman
2008-05-28 22:15   ` Alexey Zaytsev
2008-06-08 11:45     ` Detlev Zundel
2008-06-08 12:16       ` Jörn Engel
2008-05-29  2:25   ` Paul Gortmaker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8bd0f97a0805281448t1860e9abwacafb27e363dfcfb@mail.gmail.com \
    --to=vapier.adi-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=linux-embedded-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=manningc2-jEEI2ySEPisjAXWc8ALWsQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).