Well, I needed to find my way around dcaches too. :) Anyone interested
in an extended version of Documentation/filesystems/vfs.txt? I'm planning
to update it a bit to incorporate stuff from some current discussions about
the fs code, and of course from some experience, but not in the immediate
future.
> The latest result of my efforts (retrofitted from my (almost working)
> version to your version in 2.1.47) is given by the following patch. It is
Oh, thanks for the attention.
> - The checksumming function is called just once; by inlining it you'll
> probably s(h)ave a couple of bytes.
Well, it is "defined" to have checksums at more place, I just don't check
them currently. If I do, it will lose, and I believe I can just leave
it to GCC to do the good stuff.
> - If the checksum doesn't turn out right, better leave and not mount a
> probably corrupted filesystem
Maybe; it might be left from the debugging state, I'm certain it was
useful, but now I'm not so sure. :)
> - I'd better not lie about the f_namelen in statfs(). One of my trial
> versions did blow up because of that, I think...
I don't think so, it worked without it for months... df doesn't see
problems with it; maybe it would cause problems for file creation, but
that's currently impossible anyway. :)
> - I believe you could unlock_super() twice in romfs_read_super.
Oops, indeed. Last minute line shuffling is harmful to the quality of
the code.. :) BTW, the goto to_the_end ugliness is really meant to,
separate returns seem to cause the intel gcc to add separate stack
unrolls and rets, while the goto does only a short jump, so it's smaller.
It might be completely different for other architectures.
> - Instead on kmallock()ing memory for the filenames (as you propose in the
> TODO list), you could use alloca(), by way of the gcc-2.x builtin. Naughty,
> but it should work even in the kernel and cost less than kmalloc()/kfree()
> in code size...
On Fri, Jul 25, 1997 at 12:05:19PM +0200, Ingo Molnar wrote:
> i think this is dangerous, as filenames might be quite large, and alloca()
> allocates on the stack? So you'll get the 'ayiee stack corruption' stuff.
Yes, and that's the magic word for Ingo.. :) Currently, the length of
file names are quite limited, but I feel better if I can completely control
the memory usage. And the stack usage is even more dangerous.
> - You might consider using the quicklist routines from linux/fs/namei.c for
> allocating the link name. You'd gain some performance (probably not
> really worth it, but would make a good example for later generations :)
Indeed, it would be an easy way to cope with allocations but unfortunately
get_page and putname are not exported, and does not seem to be a
recommended interface to quick allocations.
Thanks for the patch and the notes. Although the double unlock needs
to be fixed soon, I think it can wait some days until I got some time
again.. :)
-- Janos - Don't worry, my address works. I'm just bored of spam.