Adrian Bunk | 1 Dec 18:11
Picon
Favicon

[2.6 patch] remove mtd/jffs2-user.h

- not included by any other header
- not defining any userspace <-> kernel interface
- depends on userspace providing a variable "target_endian"

mtd-utils already has a copy of this file.

Signed-off-by: Adrian Bunk <bunk <at> stusta.de>

---

 include/mtd/Kbuild       |    1 -
 include/mtd/jffs2-user.h |   35 -----------------------------------
 2 files changed, 36 deletions(-)

--- a/include/mtd/jffs2-user.h
+++ /dev/null
@@ -1,35 +0,0 @@
-/*
- * $Id: jffs2-user.h,v 1.1 2004/05/05 11:57:54 dwmw2 Exp $
- *
- * JFFS2 definitions for use in user space only
- */
-
-#ifndef __JFFS2_USER_H__
-#define __JFFS2_USER_H__
-
-/* This file is blessed for inclusion by userspace */
-#include <linux/jffs2.h>
-#include <endian.h>
-#include <byteswap.h>
(Continue reading)

Yan Burman | 2 Dec 12:31
Picon

[PATCH 2.6.19] jffs: replace kmalloc+memset with kzalloc

Replace kmalloc+memset with kzalloc

Signed-off-by: Yan Burman <burman.yan <at> gmail.com>

diff -rubp linux-2.6.19-rc5_orig/fs/jffs/intrep.c linux-2.6.19-rc5_kzalloc/fs/jffs/intrep.c
--- linux-2.6.19-rc5_orig/fs/jffs/intrep.c	2006-11-09 12:16:20.000000000 +0200
+++ linux-2.6.19-rc5_kzalloc/fs/jffs/intrep.c	2006-11-11 22:44:18.000000000 +0200
@@ -591,7 +591,7 @@ jffs_add_virtual_root(struct jffs_contro
 	D2(printk("jffs_add_virtual_root(): "
 		  "Creating a virtual root directory.\n"));

-	if (!(root = kmalloc(sizeof(struct jffs_file), GFP_KERNEL))) {
+	if (!(root = kzalloc(sizeof(struct jffs_file), GFP_KERNEL))) {
 		return -ENOMEM;
 	}
 	no_jffs_file++;
@@ -603,7 +603,6 @@ jffs_add_virtual_root(struct jffs_contro
 	DJM(no_jffs_node++);
 	memset(node, 0, sizeof(struct jffs_node));
 	node->ino = JFFS_MIN_INO;
-	memset(root, 0, sizeof(struct jffs_file));
 	root->ino = JFFS_MIN_INO;
 	root->mode = S_IFDIR | S_IRWXU | S_IRGRP
 		     | S_IXGRP | S_IROTH | S_IXOTH;

Jeff Garzik | 12 Dec 13:39

[PATCH/RFC] Delete JFFS (version 1)

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 <kaber <at> trash.net>

 ---------------------------
+
+What:	JFFS (version 1) filesystem
+When:	2.6.21
+Why:	No users or developers
+Who:	Jeff Garzik <jeff <at> garzik.org>
+
+---------------------------
(Continue reading)

Josh Boyer | 12 Dec 13:56
Picon

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

On 12/12/06, Jeff Garzik <jeff <at> 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
Jörn Engel | 12 Dec 13:58

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

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

Jeff Garzik | 12 Dec 14:02

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

Josh Boyer wrote:
> On 12/12/06, Jeff Garzik <jeff <at> 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

(Continue reading)

Josh Boyer | 12 Dec 14:06
Picon

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

On 12/12/06, Jeff Garzik <jeff <at> garzik.org> wrote:
> Josh Boyer wrote:
> > On 12/12/06, Jeff Garzik <jeff <at> 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.

(Continue reading)

David Woodhouse | 12 Dec 14:07
Favicon

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

On Tue, 2006-12-12 at 07:06 -0600, Josh Boyer wrote:
> On 12/12/06, Jeff Garzik <jeff <at> garzik.org> wrote:
> > Josh Boyer wrote:
> > > On 12/12/06, Jeff Garzik <jeff <at> 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.
(Continue reading)

Jeff Garzik | 12 Dec 14:09

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

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-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bill Nottingham | 12 Dec 18:01
Picon
Favicon

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

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


Gmane