Re: Q: JFFS2 RAM requirements (and other questions...)

On Sat, 2004-07-03 at 16:30 +0100, Alan Cox wrote:
> It would depend on your implementation. Given you can't use the GPL'd
> linux implementation linked to non-free software I suspect you would
> need to re-implement the JFFS2 design (or license code for it from
> some other implementor).

The JFFS2 code is released under the eCos licence so it's a little freer
than pure GPL -- you can use it in another OS but any changes you make
to the JFFS2 files themselves must be released. See
http://ecos.sourceware.org/license-overview.html

Also, it's no longer possible to obtain the current code under a
different licence. Since Red Hat IS decided without notice to terminate
services to the machines running CVS and mailing list services for the
project, I am no longer requiring that JFFS2 contributors assign
copyright to Red Hat.

> The ram dependancy is really based around the number of nodes on the
> flash and thus the number of changes in the log. You can trade that
> off against performance since you can always look for stuff through
> the flash instead of in RAM. One thing in your favour is presumably that
> you will always write entire files or large blocks if the device is a
> media player of some form while an OS tends to have files that get
> updated/changed and generate a lot of log entries.

You can reduce the number of nodes by increasing the size of them --
it's often been discussed that we could relax the restriction on data
nodes crossing a PAGE_SIZE boundary. Increasing the maximum data payload
to something like 16KiB would be helpful, and would also let us get rid
of a gratuitously platform-specific on-medium format consideration
(PAGE_SIZE varies on different architectures).

You can also look at the discussions which we had relatively recently
about eliminating the 'totlen' field from the struct jffs2_raw_node_ref.
In 99% of cases it can be inferred correctly from the physical offset of
the next node in the list; if we just fix up the remaining 1% of cases,
we can drop the field from the structure, hence reducing the structure
by 25%. I've already made all uses of it use an accessor function
ref_totlen(), and even implemented that accessor function; it's just a
case of fixing the known bugs.

-- 
dwmw2



To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to [email protected]