Messages in this thread | | | Date | Fri, 25 Jul 1997 14:58:51 +0200 | From | Janos Farkas <Janos.Farkas-#> | Subject | Re: 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.
| |