[PATCH/RFC] Delete JFFS (version 1)

[Jeff Garzik]

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

[Josh Boyer]

Post by Jeff Garzik
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

[Jeff Garzik]

Post by Josh Boyer

Post by Jeff Garzik
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



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

[Josh Boyer]

Post by Jeff Garzik

Post by Josh Boyer

Post by Jeff Garzik
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.

Post by Jeff Garzik
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
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[David Woodhouse]

Post by Josh Boyer

Post by Jeff Garzik

Post by Josh Boyer

Post by Jeff Garzik
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.

Post by Jeff Garzik
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.

[Jeff Garzik]

Post by Jeff Garzik
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


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

[Bill Nottingham]

Post by Jeff Garzik
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
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Jeff Garzik]

Post by Bill Nottingham

Post by Jeff Garzik
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



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

[Alan]

On Tue, 12 Dec 2006 12:01:25 -0500

Post by Bill Nottingham

Post by Jeff Garzik
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[David Weinehall]

Post by Alan
On Tue, 12 Dec 2006 12:01:25 -0500

Post by Bill Nottingham

Post by Jeff Garzik
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

[Jörn Engel]

=20
I have created the 'kill-jffs' branch of=20
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git th=

at=20

removes fs/jffs.
=20
I argue that you can count the users (who aren't on 2.4) on one hand,=

=20

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 si=
nce.

J=C3=B6rn

--=20
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 ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Andrew Morton]

On Tue, 12 Dec 2006 07:39:26 -0500

Post by Jeff Garzik
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.

[Josh Boyer]

Post by Andrew Morton
On Tue, 12 Dec 2006 07:39:26 -0500

Post by Jeff Garzik
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 <***@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
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Andreas Dilger]

Post by Josh Boyer

Post by Andrew Morton
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
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.

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

[Jörn Engel]

=20
It would be better to have a printk in the module init, since users w=

ith

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=C3=B6rn

--=20
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 ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[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