[Fwd: Learn from minix: fork ramfs.] - linus's ACTUAL reply.

[Fwd: Learn from minix: fork ramfs.] - linus's ACTUAL reply.

[Rob Landley]

[-- Attachment #1: Type: text/plain, Size: 108 bytes --]

Okay, the sleep situation has not improved.  I'll admit that right now. 
But it's ABOUT to.  G'night...

Rob

[-- Attachment #2: Type: message/rfc822, Size: 2195 bytes --]

From: Linus Torvalds <torvalds@transmeta.com>
To: Rob Landley <landley@flash.net>
Cc: linux-kernel@vger.rutgers.edu
Subject: Re: Learn from minix: fork ramfs.
Date: Mon, 8 Jan 2001 19:03:04 -0800 (PST)
Message-ID: <Pine.LNX.4.10.10101081900040.1371-100000@penguin.transmeta.com>



On Mon, 8 Jan 2001, Rob Landley wrote:
> 
> So fork ramfs already.  Copy the snapshot you like as an educational
> tool, call it skeletonfs.c or some such, and let the current code evolve
> into something more useful.

The thing is, that I'm not sure that even the extended ramfs is really
useful except for very controlled environments (ie initrd-type things
where the contents of the ramdisk is _controlled_, and as such the
addition of limits is not necessarily all that useful a feature). Others
have spoken up on why tmpfs isn't a good thing either, with good
arguments.

So it's not all about teaching.

I think the ramfs limit code has a good argument from Alan for embedded
devices, so that probably will make it in. However, even so it's obviously
not a 2.4.1 issue, AND as shown by the fact that apparently the thing is
buggy and still worked on I wouldn't want the patches right now in the
first place.

		Linus