Re: Stable cvs version for 2.4

[David Woodhouse <dwmw2@infradead.org>]

jasmine@hex.linuxgrrls.org said:
>  Is there nowhere that's not a pointer that you can stuff it? 

struct jffs2_node_frag
{
	rb_node_t rb;
	struct jffs2_full_dnode *node; /* NULL for holes */
	uint32_t size;
	uint32_t ofs; /* Don't really need this, but optimisation */
};

Not really. 'size' and 'ofs' are within the file -- so if you open a file,
seek to 0xFFFFFFFD and write a byte, you can quite happily end up with a
hole frag with size=0xFFFFFFFD and a subsequent data frag with the same ofs.
So I can't abuse the high or low bits like I do with the physical offsets on
the flash in the jffs2_raw_node_ref.

And although I thought at the time that 'size' was an optimisation I don't 
really think it is any more.

Although actually perhaps it is. Must investigate that possibility too -- no
reason why I can't assume that 'frag->size' is always equivalent to
'frag_next(frag)->ofs - frag->ofs', as long as I stick in an end-marker to
show the size of the last frag, if I can stick 0xFFFFFFFF in the 'node'
pointer to mark that or something. Or if you'd shoot me for that too I could
allocate something at boot and use _that_ address as the 'end marker' in the
knowledge that it's not ambiguous.

--
dwmw2