[PATCH/RFC] Delete JFFS (version 1)

[PATCH/RFC] Delete JFFS (version 1)

[Jeff Garzik]

[-- Attachment #1: Type: text/plain, Size: 361 bytes --]

I have created the 'kill-jffs' branch of 
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git that 
removes fs/jffs.

I argue that you can count the users (who aren't on 2.4) on one hand, 
and developers don't seem to have cared for it in ages.

People are already talking about jffs2 replacements, so I propose we zap 
jffs in 2.6.21.

	Jeff




[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 538 bytes --]

diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 46f2a55..c008303 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -270,3 +270,10 @@ Why:	The new layer 3 independant connection tracking replaces the old
 Who:	Patrick McHardy <kaber@trash.net>
 
 ---------------------------
+
+What:	JFFS (version 1) filesystem
+When:	2.6.21
+Why:	No users or developers
+Who:	Jeff Garzik <jeff@garzik.org>
+
+---------------------------

Re: [PATCH/RFC] Delete JFFS (version 1)

[Josh Boyer]

On 12/12/06, Jeff Garzik <jeff@garzik.org> wrote:
> I have created the 'kill-jffs' branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git that
> removes fs/jffs.
>
> I argue that you can count the users (who aren't on 2.4) on one hand,
> and developers don't seem to have cared for it in ages.
>
> People are already talking about jffs2 replacements, so I propose we zap
> jffs in 2.6.21.

I'm usually all for killing broken code, but JFFS isn't really broken
is it?  Is there some burden it's causing by being in the kernel at
the moment?

josh

Re: [PATCH/RFC] Delete JFFS (version 1)

[Jeff Garzik]

Josh Boyer wrote:
> On 12/12/06, Jeff Garzik <jeff@garzik.org> wrote:
>> I have created the 'kill-jffs' branch of
>> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git that
>> removes fs/jffs.
>>
>> I argue that you can count the users (who aren't on 2.4) on one hand,
>> and developers don't seem to have cared for it in ages.
>>
>> People are already talking about jffs2 replacements, so I propose we zap
>> jffs in 2.6.21.
> 
> I'm usually all for killing broken code, but JFFS isn't really broken
> is it?  Is there some burden it's causing by being in the kernel at
> the moment?

It's always been the case that we remove Linux kernel code when the 
number of users (and more importantly, developers) drops to near-nil.

Every line of code is one more place you have to audit when code 
changes, one more place to update each time the VFS API is touched.

When it's more likely to get struck by lightning than encounter 
filesystem X on a random hard drive in the field, filesystem X need not 
be in the kernel.

IMO, of course :)

	Jeff

Re: [PATCH/RFC] Delete JFFS (version 1)

[Josh Boyer]

On 12/12/06, Jeff Garzik <jeff@garzik.org> wrote:
> Josh Boyer wrote:
> > On 12/12/06, Jeff Garzik <jeff@garzik.org> wrote:
> >> I have created the 'kill-jffs' branch of
> >> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git that
> >> removes fs/jffs.
> >>
> >> I argue that you can count the users (who aren't on 2.4) on one hand,
> >> and developers don't seem to have cared for it in ages.
> >>
> >> People are already talking about jffs2 replacements, so I propose we zap
> >> jffs in 2.6.21.
> >
> > I'm usually all for killing broken code, but JFFS isn't really broken
> > is it?  Is there some burden it's causing by being in the kernel at
> > the moment?
>
> It's always been the case that we remove Linux kernel code when the
> number of users (and more importantly, developers) drops to near-nil.
>
> Every line of code is one more place you have to audit when code
> changes, one more place to update each time the VFS API is touched.

Ok, I can buy that.

>
> When it's more likely to get struck by lightning than encounter
> filesystem X on a random hard drive in the field, filesystem X need not
> be in the kernel.

Or flash chip in this case ;)

josh

Re: [PATCH/RFC] Delete JFFS (version 1)

[David Woodhouse]

On Tue, 2006-12-12 at 07:06 -0600, Josh Boyer wrote:
> On 12/12/06, Jeff Garzik <jeff@garzik.org> wrote:
> > Josh Boyer wrote:
> > > On 12/12/06, Jeff Garzik <jeff@garzik.org> wrote:
> > >> I have created the 'kill-jffs' branch of
> > >> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git that
> > >> removes fs/jffs.
> > >>
> > >> I argue that you can count the users (who aren't on 2.4) on one hand,
> > >> and developers don't seem to have cared for it in ages.
> > >>
> > >> People are already talking about jffs2 replacements, so I propose we zap
> > >> jffs in 2.6.21.
> > >
> > > I'm usually all for killing broken code, but JFFS isn't really broken
> > > is it?  Is there some burden it's causing by being in the kernel at
> > > the moment?
> >
> > It's always been the case that we remove Linux kernel code when the
> > number of users (and more importantly, developers) drops to near-nil.
> >
> > Every line of code is one more place you have to audit when code
> > changes, one more place to update each time the VFS API is touched.
> 
> Ok, I can buy that.
> 
> >
> > When it's more likely to get struck by lightning than encounter
> > filesystem X on a random hard drive in the field, filesystem X need not
> > be in the kernel.
> 
> Or flash chip in this case ;)

More to the point, people have occasionally actually _used_ JFFS instead
of JFFS2. I'm all for removing it now.

-- 
dwmw2

Re: [PATCH/RFC] Delete JFFS (version 1)

[Jeff Garzik]

Jeff Garzik wrote:
> When it's more likely to get struck by lightning than encounter 
> filesystem X on a random hard drive in the field, filesystem X need not 
> be in the kernel.

As people are already poking me:)  I course meant "flash device" not 
"hard drive".

SATA maintainer's curse, I suppose, to think of all storage devices as 
hard drives, no matter how incorrect that might be :)

	Jeff

Re: [PATCH/RFC] Delete JFFS (version 1)

[Bill Nottingham]

Jeff Garzik (jeff@garzik.org) said: 
> It's always been the case that we remove Linux kernel code when the 
> number of users (and more importantly, developers) drops to near-nil.

So, drivers/net/3c501.c?

Bill

Re: [PATCH/RFC] Delete JFFS (version 1)

[Jeff Garzik]

Bill Nottingham wrote:
> Jeff Garzik (jeff@garzik.org) said: 
>> It's always been the case that we remove Linux kernel code when the 
>> number of users (and more importantly, developers) drops to near-nil.
> 
> So, drivers/net/3c501.c?

Depends on how motivated Alan remains ;-)  Historically, if the 
developer is active, we have occasionally ignored the miniscule userbase.

	Jeff

Re: [PATCH/RFC] Delete JFFS (version 1)

[Alan]

On Tue, 12 Dec 2006 12:01:25 -0500
Bill Nottingham <notting@redhat.com> wrote:

> Jeff Garzik (jeff@garzik.org) said: 
> > It's always been the case that we remove Linux kernel code when the 
> > number of users (and more importantly, developers) drops to near-nil.
> 
> So, drivers/net/3c501.c?

I think 3c501.c is a case where putting in an "If you use this email ..
or it will go away" might be a good idea indeed.

Re: [PATCH/RFC] Delete JFFS (version 1)

[David Weinehall]

On Tue, Dec 12, 2006 at 05:28:43PM +0000, Alan wrote:
> On Tue, 12 Dec 2006 12:01:25 -0500
> Bill Nottingham <notting@redhat.com> wrote:
> 
> > Jeff Garzik (jeff@garzik.org) said: 
> > > It's always been the case that we remove Linux kernel code when the 
> > > number of users (and more importantly, developers) drops to near-nil.
> > 
> > So, drivers/net/3c501.c?
> 
> I think 3c501.c is a case where putting in an "If you use this email ..
> or it will go away" might be a good idea indeed.

Maybe even: "the people who are using 3c501's - please chime up and we'll
donate better cards to you."

After all, 3c501 is one of the crappier pieces of network cards,
I feel sorry for the people using them...


Regards: David
-- 
 /) David Weinehall <tao@acc.umu.se> /) Northern lights wander      (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/    (/   Full colour fire           (/

Re: [PATCH/RFC] Delete JFFS (version 1)

[Jörn Engel]

On Tue, 12 December 2006 07:39:26 -0500, Jeff Garzik wrote:
> 
> I have created the 'kill-jffs' branch of 
> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git that 
> removes fs/jffs.
> 
> I argue that you can count the users (who aren't on 2.4) on one hand, 
> and developers don't seem to have cared for it in ages.

You can count them on one finger, I guess.  The last time jffs was
proposed for removal, a single person said he still used it and would
like to keep it around.  And I haven't seen any patches come forward since.

Jörn

-- 
Don't patch bad code, rewrite it.
-- Kernigham and Pike, according to Rusty
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC] Delete JFFS (version 1)

[Andrew Morton]

On Tue, 12 Dec 2006 07:39:26 -0500
Jeff Garzik <jeff@garzik.org> wrote:

> I have created the 'kill-jffs' branch of 
> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git that 
> removes fs/jffs.
> 
> I argue that you can count the users (who aren't on 2.4) on one hand, 
> and developers don't seem to have cared for it in ages.
> 
> People are already talking about jffs2 replacements, so I propose we zap 
> jffs in 2.6.21.

It would be good to provide unignorable notice of this in 2.6.20.  Via a
loud printk, or perhaps even CONFIG_BROKEN or CONFIG_EMBEDDED.

Re: [PATCH/RFC] Delete JFFS (version 1)

[Josh Boyer]

On 12/12/06, Andrew Morton <akpm@osdl.org> wrote:
> On Tue, 12 Dec 2006 07:39:26 -0500
> Jeff Garzik <jeff@garzik.org> wrote:
>
> > I have created the 'kill-jffs' branch of
> > git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git that
> > removes fs/jffs.
> >
> > I argue that you can count the users (who aren't on 2.4) on one hand,
> > and developers don't seem to have cared for it in ages.
> >
> > People are already talking about jffs2 replacements, so I propose we zap
> > jffs in 2.6.21.
>
> It would be good to provide unignorable notice of this in 2.6.20.  Via a
> loud printk, or perhaps even CONFIG_BROKEN or CONFIG_EMBEDDED.

Something like the below?

Make CONFIG_JFFS depend on CONFIG_BROKEN

Signed-off-by: Josh Boyer <jwboyer@gmail.com>

diff --git a/fs/Kconfig b/fs/Kconfig
index b3b5aa0..4ac367d 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -1204,13 +1204,16 @@ config EFS_FS

 config JFFS_FS
 	tristate "Journalling Flash File System (JFFS) support"
-	depends on MTD && BLOCK
+	depends on MTD && BLOCK && BROKEN
 	help
 	  JFFS is the Journalling Flash File System developed by Axis
 	  Communications in Sweden, aimed at providing a crash/powerdown-safe
 	  file system for disk-less embedded devices. Further information is
 	  available at (<http://developer.axis.com/software/jffs/>).

+	  NOTE: This filesystem is deprecated and is scheduled for removal in
+	  2.6.21.  See Documentation/feature-removal-schedule.txt
+
 config JFFS_FS_VERBOSE
 	int "JFFS debugging verbosity (0 = quiet, 3 = noisy)"
 	depends on JFFS_FS

Re: [PATCH/RFC] Delete JFFS (version 1)

[Andreas Dilger]

On Dec 12, 2006  12:38 -0600, Josh Boyer wrote:
> On 12/12/06, Andrew Morton <akpm@osdl.org> wrote:
> >It would be good to provide unignorable notice of this in 2.6.20.  Via a
> >loud printk, or perhaps even CONFIG_BROKEN or CONFIG_EMBEDDED.
> 
> Something like the below?
> 
> Make CONFIG_JFFS depend on CONFIG_BROKEN
> 
> Signed-off-by: Josh Boyer <jwboyer@gmail.com>
> 
> diff --git a/fs/Kconfig b/fs/Kconfig
> index b3b5aa0..4ac367d 100644
> --- a/fs/Kconfig
> +++ b/fs/Kconfig
> @@ -1204,13 +1204,16 @@ config EFS_FS
> 
> config JFFS_FS
> 	tristate "Journalling Flash File System (JFFS) support"
> -	depends on MTD && BLOCK
> +	depends on MTD && BLOCK && BROKEN
> 	help
> 	  JFFS is the Journalling Flash File System developed by Axis
> 	  Communications in Sweden, aimed at providing a crash/powerdown-safe
> 	  file system for disk-less embedded devices. Further information is
> 	  available at (<http://developer.axis.com/software/jffs/>).
> 
> +	  NOTE: This filesystem is deprecated and is scheduled for removal in
> +	  2.6.21.  See Documentation/feature-removal-schedule.txt
> +

It would be better to have a printk in the module init, since users with
upstream builds won't see the config help.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

Re: [PATCH/RFC] Delete JFFS (version 1)

[Jörn Engel]

On Tue, 12 December 2006 14:49:04 -0700, Andreas Dilger wrote:
> 
> It would be better to have a printk in the module init, since users with
> upstream builds won't see the config help.

How many of those are there?  This is not ext3, this is a flash
filesystem.  Users are either those doing the upstream build or they
won't ever see a console.  Think DSL-Router. ;)

Jörn

-- 
Joern's library part 14:
http://www.sandpile.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC] Delete JFFS (version 1)

[Stefan Monnier]

> I argue that you can count the users (who aren't on 2.4) on one hand, and
> developers don't seem to have cared for it in ages.

Rather than ask on mailing-lists, it's probably easier to just make the jffs
compilation fail (with a #error).  This way, if someone uses it, he'll bump
into it, no matter how much he wants to ignore messages posted on
mailing-lists.


        Stefan