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 <[email protected]>
---------------------------
+
+What: JFFS (version 1) filesystem
+When: 2.6.21
+Why: No users or developers
+Who: Jeff Garzik <[email protected]>
+
+---------------------------
On 12/12/06, Jeff Garzik <[email protected]> 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
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
Josh Boyer wrote:
> On 12/12/06, Jeff Garzik <[email protected]> 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
On 12/12/06, Jeff Garzik <[email protected]> wrote:
> Josh Boyer wrote:
> > On 12/12/06, Jeff Garzik <[email protected]> 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
On Tue, 2006-12-12 at 07:06 -0600, Josh Boyer wrote:
> On 12/12/06, Jeff Garzik <[email protected]> wrote:
> > Josh Boyer wrote:
> > > On 12/12/06, Jeff Garzik <[email protected]> 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
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
Jeff Garzik ([email protected]) 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
Bill Nottingham wrote:
> Jeff Garzik ([email protected]) 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
On Tue, 12 Dec 2006 12:01:25 -0500
Bill Nottingham <[email protected]> wrote:
> Jeff Garzik ([email protected]) 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.
On Tue, 12 Dec 2006 07:39:26 -0500
Jeff Garzik <[email protected]> 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.
On 12/12/06, Andrew Morton <[email protected]> wrote:
> On Tue, 12 Dec 2006 07:39:26 -0500
> Jeff Garzik <[email protected]> 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 <[email protected]>
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
On Dec 12, 2006 12:38 -0600, Josh Boyer wrote:
> On 12/12/06, Andrew Morton <[email protected]> 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 <[email protected]>
>
> 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.
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/
On Tue, Dec 12, 2006 at 05:28:43PM +0000, Alan wrote:
> On Tue, 12 Dec 2006 12:01:25 -0500
> Bill Nottingham <[email protected]> wrote:
>
> > Jeff Garzik ([email protected]) 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 <[email protected]> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/