headers
Adrian Bunk | 1 Nov 21:51
Picon
Favicon

[RFC: 2.6 patch] remove fs/jffs2/ioctl.c

Is there any reason for keeping fs/jffs2/ioctl.c?

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

---

 fs/jffs2/Makefile   |    2 +-
 fs/jffs2/dir.c      |    1 -
 fs/jffs2/file.c     |    1 -
 fs/jffs2/ioctl.c    |   23 -----------------------
 fs/jffs2/os-linux.h |    3 ---
 5 files changed, 1 insertion(+), 29 deletions(-)

--- linux-2.6.14-rc5-mm1-full/fs/jffs2/os-linux.h.old	2005-11-01 20:28:24.000000000 +0100
+++ linux-2.6.14-rc5-mm1-full/fs/jffs2/os-linux.h	2005-11-01 20:28:31.000000000 +0100
@@ -147,9 +147,6 @@
 int jffs2_fsync(struct file *, struct dentry *, int);
 int jffs2_do_readpage_unlock (struct inode *inode, struct page *pg);

-/* ioctl.c */
-int jffs2_ioctl(struct inode *, struct file *, unsigned int, unsigned long);
-
 /* symlink.c */
 extern struct inode_operations jffs2_symlink_inode_operations;

--- linux-2.6.14-rc5-mm1-full/fs/jffs2/dir.c.old	2005-11-01 20:28:39.000000000 +0100
+++ linux-2.6.14-rc5-mm1-full/fs/jffs2/dir.c	2005-11-01 20:28:43.000000000 +0100
@@ -41,7 +41,6 @@
 {
 	.read =		generic_read_dir,
(Continue reading)

Permalink | Reply | 4 comments |
headers
Adrian Bunk | 1 Nov 21:49
Picon
Favicon

[2.6 patch] jffs_fm.c should #include "intrep.h"

Every file should #include the headers containing the prototypes for
it's global functions.

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

--- linux-2.6.14-rc5-mm1-full/fs/jffs/jffs_fm.c.old	2005-11-01 20:25:45.000000000 +0100
+++ linux-2.6.14-rc5-mm1-full/fs/jffs/jffs_fm.c	2005-11-01 20:26:01.000000000 +0100
@@ -20,6 +20,7 @@
 #include <linux/blkdev.h>
 #include <linux/jffs.h>
 #include "jffs_fm.h"
+#include "intrep.h"

 #if defined(JFFS_MARK_OBSOLETE) && JFFS_MARK_OBSOLETE
 static int jffs_mark_obsolete(struct jffs_fmcontrol *fmc, __u32 fm_offset);
Permalink | Reply | 0 comments |
headers
Josh Boyer | 1 Nov 22:10
Picon
Favicon

Re: [RFC: 2.6 patch] remove fs/jffs2/ioctl.c

On Tue, 2005-11-01 at 21:51 +0100, Adrian Bunk wrote:
> Is there any reason for keeping fs/jffs2/ioctl.c?

I can think of some various things that could be done with it, but that
would require time and effort.  Unless David or Thomas have an
objections, I think it can go.

josh
Permalink | Reply | 2 comments |
headers
Jörn Engel | 2 Nov 10:47
Picon

Re: [RFC: 2.6 patch] remove fs/jffs2/ioctl.c

On Tue, 1 November 2005 15:10:36 -0600, Josh Boyer wrote:
> On Tue, 2005-11-01 at 21:51 +0100, Adrian Bunk wrote:
> > Is there any reason for keeping fs/jffs2/ioctl.c?
> 
> I can think of some various things that could be done with it, but that
> would require time and effort.  Unless David or Thomas have an
> objections, I think it can go.

And for the last couple of years, no problem seemed urgent enough for
someone to actually implement something.  I vote for removal.

Jörn

--

-- 
This above all: to thine own self be true.
-- Shakespeare
Permalink | Reply | 0 comments |
headers
Adam Dosch | 7 Nov 23:58

JFFS2 garbage collection daemon in Kernel 2.6.14

Hi,

I've been in the process of implementing Linux kernel 2.6 (specifically now
2.6.14) on an IXP425 development board.

When the kernel boosts, it will mount the jffs2 flash partition and start to
initialize `init`, then I start getting a soft lock errors like:

   BUG: soft lockup detected on CPU#0!

Alot of these are caused by some custom software that is executed on the
filesyste that was written for kernel 2.4.  Once I stop that from executing on
bootup, my other problem lies with the JFFS2 garbage collection daemon that is
initialized as a kernel thread/process ./fs/jffs2/background.c, line 75.

I've commented out the line so the JFFS2 garbage collection daemon doesnt
initialize at all as that kernel process/thread and I have a stable filesystem
as far as I can tell.

I was curious though; I know stopped the error from coming up, but I want to
know if not having the garbage collection daemon running is a bad idea?  From a
forum post back in August 2000 (http://mhonarc.axis.se/jffs-dev/msg00123.html)
it was said that it's not that big of deal b/c, at most, instead of keeping the
filesystem constantly in-check and fresh, if/when the filesystem runs out of
space, the garbage collection mechanism will kick in anyway.

Is that still safe to assume now?  Or am I doing something wrong when
implementing the JFFS2 filesystem under 2.6?  Or maybe it was just the older
software that was doing it all along.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Longzhe Han | 15 Nov 15:30
Picon

magic number of jffs2

Hello,

the first field of the struct jffs2_unknown_node is magic, this number is
used to distinguish itself from jffs2_raw_inode and jffs2_raw_dirent.

my questions are:
1. what if the magic number appears on other place for example data block?
2. if I want to add new node type on the flash, how to choose new magic 
number?

Thanks a lot.

Longzhe Han

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo <at> axis.com
Permalink | Reply | 0 comments |
headers
Longzhe Han | 16 Nov 04:00
Picon

Re: magic number of jffs2

I am clear, thank you very much Mr. Bityutskiy.

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo <at> axis.com
Permalink | Reply | 0 comments |
headers
Mads leMaire | 22 Nov 12:12
Favicon

Kernel bug -jffs2

Hi,

While booting my embedded system I may run into the following bug depending on the order I start my applications:

----------------------------------------------------------------------------------------------------------------------
....kernel boot messages........
Checked all inodes but still 0x1e0dd8 bytes of unchecked space?
kernel BUG at gc.c:138!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000, *pmd = 00000000
Internal error: Oops: 807
CPU: 0
pc : [<c0032d20>]    lr : [<c003b09c>]    Tainted: PF
sp : c3be1ee4  ip : c3be1eb0  fp : c3be1ef4
r10: 00000000  r9 : c03641d8  r8 : c3be1f1c
r7 : c036411c  r6 : c03640ec  r5 : c3be1f0c  r4 : 00000000
r3 : 00000000  r2 : 00000001  r1 : 00000001  r0 : 00000001
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment user
Control: 397F  Table: A3B14000  DAC: 00000015
Process jffs2_gcd_mtd3 (pid: 14, stack limit = 0xc3be036c)
Stack: (0xc3be1ee4 to 0xc3be2000)
1ee0:          c3be0000 c3be1f54 c3be1ef8 c009b220 c0032cec c3be1f04 c0054ca4 
1f00: c0055494 c3faa0a0 c3be1f38 00000000 c3be0000 00000000 00000000 00000000 
1f20: c3be0000 00000000 00000000 c3be0000 c3be0000 c03640ec c3be1f58 00000000 
1f40: c3c0de94 c0364000 c3be1ff4 c3be1f58 c009e220 c009b034 00000001 00000000 
1f60: 00000080 00000000 00000000 00000000 00000000 00000001 fffe67b7 ffdfdff6 
1f80: 00000000 00000000 00000013 00000000 00000000 00000000 00000000 00000000 
1fa0: 00000000 c3be1fb0 c002d84c c00377e8 00000000 00000000 00000600 00000001 
1fc0: c009e0b4 c3c0c000 00000000 c126da00 00000000 c3c0de94 c009e0b4 c3c0c000
(Continue reading)

Permalink | Reply | 0 comments |

Gmane