From: Rob Landley <landley@flash.net>
To: linux-kernel@vger.kernel.org
Subject: [Fwd: Learn from minix: fork ramfs.] - linus's ACTUAL reply.
Date: Tue, 09 Jan 2001 17:19:59 -0600 [thread overview]
Message-ID: <3A5B9C9F.2A698B60@flash.net> (raw)
[-- 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
reply other threads:[~2001-01-10 4:06 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3A5B9C9F.2A698B60@flash.net \
--to=landley@flash.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.