Hi David,

On Fri, 14 Dec 2001, David Gibson wrote:
>> But the core of shmem is always compiled. And the rest is as simple
>> as ramfs...
> 
> The point of keeping ramfs simple isn't to reduce the kernel image
> size, it's to keep it useful as an example of how to make a trivial
> filesystem.

>From this point of view I prefer the oversimplified version in the
stock kernel. We should probably correct the comment about missing
features like limits and timestamps and tag it as experimental.  But
IMHO this version explains the underlying concept best.


If we want a useable ramfs implementation we should try to keep the
image size down and try to make it as similar to tmpfs as
possible. This would keep the administrators overhead low.

I append two cummulative patches against 2.4.17-rc1 (only slightly
tested):

1) Add removepage to the addresspace_operations to simplify
   shmem.c. This is taken from your ramfs limits patch.
2) Add support for a ramfs2 filesystem type to shmem.c. The only
   feature missing compared to ramfs + limits are loopback devices on
   top of ramfs files. It does not add memory need compared to
   ramfs. Have a look how small this is.

We could do 2 without 1 but it would need some review of the
calculation of the inode sizes.

Greetings
		Christoph