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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Dec 23 2001 - 21:00:11 EST