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

2007-03-09 Thread 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2006-12-19 Thread David Weinehall 
On Tue, Dec 12, 2006 at 05:28:43PM +, 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   (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2006-12-13 Thread 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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2006-12-12 Thread Andreas Dilger 
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 ().
> 
> +   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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2006-12-12 Thread Josh Boyer 

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 ().

+ 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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2006-12-12 Thread Andrew Morton 
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2006-12-12 Thread Jeff Garzik 

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



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2006-12-12 Thread Alan 
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2006-12-12 Thread Bill Nottingham 
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2006-12-12 Thread 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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2006-12-12 Thread Josh Boyer 

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2006-12-12 Thread David Woodhouse 
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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2006-12-12 Thread Jeff Garzik 

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



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2006-12-12 Thread 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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2006-12-12 Thread Josh Boyer 

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH/RFC] Delete JFFS (version 1)

2006-12-12 Thread 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



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]>
+
+---