headers
Ferenc Havasi | 1 Oct 13:37
Picon
Favicon

Re: How to load a file from kernel?

> Almost everything works but I've problem at loading the model files.
> I know the inode number of the file, I can "iget" it and see its
> attributes, allocate memory for it. It's OK. But if I try to read the
> content of the file by jffs2_read_inode_range() there will be a lots of
>
> Sep 27 22:07:45 kpax vmunix: bad: scheduling while atomic!

I still don't know the reason of that error messages above, but I
find a better way to load model file at mount time. Now I do it "by hand",
using ino_cache, and a way similar to one is described in
jffs2_read_dnode().

Regards,
Ferenc

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo <at> axis.com
Permalink | Reply | 1 comment |
headers
David Woodhouse | 4 Oct 17:33
Favicon

Re: How to load a file from kernel?

On Fri, 2004-10-01 at 13:37 +0200, Ferenc Havasi wrote:
> > Almost everything works but I've problem at loading the model files.
> > I know the inode number of the file, I can "iget" it and see its
> > attributes, allocate memory for it. It's OK. But if I try to read the
> > content of the file by jffs2_read_inode_range() there will be a lots of
> >
> > Sep 27 22:07:45 kpax vmunix: bad: scheduling while atomic!
> 
> I still don't know the reason of that error messages above, but I
> find a better way to load model file at mount time.

It happens because you call a function which may sleep, from a context
where that's not allowed. Probably because you're holding a spinlock.

--

-- 
dwmw2

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
Ferenc Havasi | 6 Oct 17:52
Picon
Favicon

bug in nodemgmt.c?

Dear All,

During the final testing of my model-based-patch I think I found a bug 
in fs/jffs2/nodemgmt.c

In function jffs2_mark_node_obsolete() at the part of "Merge with the 
next node in the physical list, if there is one and if it's also 
obsolete" there is a comment: "we don't need to check jeb->last_node".

Is it right? Because I think we should deal with jeb->last_node here, or 
should not use "D1(ACCT_PARANOIA_CHECK(jeb));" statement any more, but 
now it is used by also this function.

ACCT_PARANOIA_CHECK walk throught the nodes (using next_phys) and if at 
the end of the list is not equals to jeb->last_node than halts. 
Unfortunatelly with simple "NULL pointer dereference" without any 
usefull messages.

Just say I'm right and I fix this problem in the CVS (a single
"if (jeb->last_node == n) jeb->last_node=ref;" line into nodemgmt.c and 
better message in ACCT_PARANOIA_CHECK).

Regards,
Ferenc

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ferenc Havasi | 7 Oct 14:40
Picon
Favicon

model based compressor support

Hi David,

I finished the implementation of model based compressor support for JFFS2.

David, I would like to ask you: may I commit it to CVS? (certainly after 
it you can modify there anything you like/dont't like)

We had some discussion about it some month ago, I tried to follow that: 
model files now aren't "normal" files. They have no dentry only inode. I 
introduced a new kind of node:

#define JFFS2_NODETYPE_MODELINFO (JFFS2_FEATURE_INCOMPAT | 
JFFS2_NODE_ACCURATE | 5)

This node only stores an array with the inode numbers (and sizes) of the 
model files. After scaning of the flash the nlink of the inodes of model 
files are setted to 1. At the end of the mount process model files will 
be loaded "by hand". (the method is simililar the method of 
jffs2_read_dnode()).

Model files have an 8 bytes header: the first 4 is a magic 'J2MF', the 
next two is the compr and serial (usercompr), next two is reserved to 0. 
After loading the model file the corresponding compressor is called to 
initilize it (if that wants).

I modified gc to handle this MODELINFO correctly (just copy if 
neccesarry). I found a "FIXME" to handle JFFS2_NODETYPE_RWCOMPAT_COPY 
nodes, too, I implemented it in the same function.

I exended the Kconfig with the ability for users to set the priority of
(Continue reading)

Permalink | Reply | 11 comments |
headers
David Woodhouse | 7 Oct 16:34
Favicon

Re: bug in nodemgmt.c?

On Wed, 2004-10-06 at 17:52 +0200, Ferenc Havasi wrote:
> Dear All,
> 
> During the final testing of my model-based-patch I think I found a bug 
> in fs/jffs2/nodemgmt.c
> 
> In function jffs2_mark_node_obsolete() at the part of "Merge with the 
> next node in the physical list, if there is one and if it's also 
> obsolete" there is a comment: "we don't need to check jeb->last_node".
> 
> Is it right? Because I think we should deal with jeb->last_node here, or 
> should not use "D1(ACCT_PARANOIA_CHECK(jeb));" statement any more, but 
> now it is used by also this function.
> 
> ACCT_PARANOIA_CHECK walk throught the nodes (using next_phys) and if at 
> the end of the list is not equals to jeb->last_node than halts. 
> Unfortunatelly with simple "NULL pointer dereference" without any 
> usefull messages.
> 
> Just say I'm right and I fix this problem in the CVS (a single
> "if (jeb->last_node == n) jeb->last_node=ref;" line into nodemgmt.c and 
> better message in ACCT_PARANOIA_CHECK).

I think you're probably right. Øyvind, didn't we come across this
already? Did you commit an older version of your patch?

--

-- 
dwmw2

______________________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Woodhouse | 7 Oct 16:36
Favicon

Re: model based compressor support

On Thu, 2004-10-07 at 14:40 +0200, Ferenc Havasi wrote:
> Hi David,
> 
> I finished the implementation of model based compressor support for JFFS2.
> 
> David, I would like to ask you: may I commit it to CVS? (certainly after 
> it you can modify there anything you like/dont't like)

Looks good in general. I was just psyching myself up to send an update
to Linus though -- can we hold off for just a little while until that's
done?

--

-- 
dwmw2

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo <at> axis.com
Permalink | Reply | 2 comments |
headers
Ferenc Havasi | 7 Oct 16:55
Picon
Favicon

Re: model based compressor support

David Woodhouse wrote:
>>David, I would like to ask you: may I commit it to CVS? (certainly after 
>>it you can modify there anything you like/dont't like)
> 
> Looks good in general. I was just psyching myself up to send an update
> to Linus though -- can we hold off for just a little while until that's
> done?

Yes, of course. Write me if you are ready. Thanks.

But maybe the nodemgmt.c bug should be fixed before the update for 
Linus. (Shall I do it?)

Ferenc

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo <at> axis.com
Permalink | Reply | 1 comment |
headers
David Woodhouse | 7 Oct 16:59
Favicon

Re: model based compressor support

On Thu, 2004-10-07 at 16:55 +0200, Ferenc Havasi wrote:
> But maybe the nodemgmt.c bug should be fixed before the update for 
> Linus. (Shall I do it?)

Yes please. Thanks for testing. 

--

-- 
dwmw2

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
Joakim Tjernlund | 7 Oct 17:31
Picon

RE: model based compressor support

> In mkfs.jffs2 I intoduced a "compression configuration" concept. It is a 
> string with comma separated words. Every word can be a name of the 
> compressor (with priority, optoinally), or a compression mode. The 
> default value of it is "priority,zlib:70,rtime:60". It equals the 
> behavior of the original mkfs.jffs2. New switches of the mkfs.jffs2:
> 
> -C, --default-compr-config=CONFIG: Set the default compression 
> configuration.
> 
> -F, --compressor-config-file=FILENAME: Specifies a compression config 
> file. In this config  file  every line must be in format 
> "FILENAME;TYPE;COMPRESSION_CONFIG", where FILENAME is a relative file 
> name, TYPE can be only  one  of  the file  or  model keywords, and 
> COMPRESSOIN_CONFIG must be a valid compression configuration. This 
> specified  file will  be  compressed the specified compressor 
> configuration. All of the non specified files will be  compressed  by 
> the  default compression  configuration.   For  example a line of this 
> config file can  be:  "boot/zImage;file;priority,zlib:60,rtime:50",  an 
> other example: "model.armlib;model;zlib:60".

Is it possible to specify that all files in a specific directory should
be uncompressed? How?

 Jocke

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo <at> axis.com
Permalink | Reply | 7 comments |
headers
Ferenc Havasi | 7 Oct 22:30
Picon
Favicon

Re: model based compressor support

Joakim Tjernlund wrote:
> Is it possible to specify that all files in a specific directory should
> be uncompressed? How?

In this version you can specify compressor configuration only for files 
not for subdirectories.

But it is good idea! I will extend this possiblity for subdirectories 
(not too much work).

If it is urgent I can send a patch for you soon (with an example how to 
use it).

Ferenc

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo <at> axis.com
Permalink | Reply | 6 comments |

Gmane