[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
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.
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to email@example.com