lkml.org 
[lkml]   [1997]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: romfs in linux-2.1.47
On Thu, Jul 24, 1997 at 10:30:18PM -0400, Horst von Brand wrote:
> I was trying to learn more about Linux' filesystems by updating romfs for
> dcache et al, but you beat me to it. Learned a lot, though ;-) Many thanks!

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.

\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.050 / U:0.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site