From: Christoph Rohland <cr@sap.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: Tachino Nobuhiro <tachino@open.nm.fujitsu.co.jp>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Padraig Brady <padraig@antefacto.com>,
"Roy S.C. Ho" <scho1208@yahoo.com>,
linux-kernel@vger.kernel.org
Subject: Re: question about kernel 2.4 ramdisk
Date: 08 Dec 2001 10:53:48 +0100 [thread overview]
Message-ID: <m3snamhwle.fsf@linux.local> (raw)
In-Reply-To: <3C0D2843.5060708@antefacto.com> <E16BLxI-0003Ic-00@the-village.bc.nu> <snaqhzhj.wl@nisaaru.dvs.cs.fujitsu.co.jp> <m3wv02oz2w.fsf@linux.local> <20011206173755.D16513@zax>
Hi David,
On Thu, 6 Dec 2001, David Gibson wrote:
> The options are different because the ramfs limits patch predates
> shmfs.
But tmpfs made it earlier into the kernel and if we want to merge the
ramfs patch we should unify the options.
>> Further thought: Wouldn't it be better to add a no_swap mount
>> option to shmem and try to merge the two? There is a lot of code
>> duplication between mm/shmem.c and fs/ramfs/inode.c.
>
> Possibly. In fact the patch to fs/ramfs/inode.c will be
> insufficient - the limits patch also requires a change to struct
> address_space_operations in fs.h, and also a change in mm/pagemap.c.
> shmfs applies the limits in a different way which doesn't need this, I
> haven't looked at it enough to see how it's done - by the time shmfs
> came around I'd moved on from the ramfs stuff.
I thought the patch in question does it without the removepage
operation.
> On the other hand one of the nice things about ramfs is it's
> simplicity and ramfs with limits is quite a bit less complex than
> shmfs.
But the core of shmem is always compiled. And the rest is as simple as
ramfs...
Greetings
Christoph
next prev parent reply other threads:[~2001-12-08 9:58 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-04 19:01 question about kernel 2.4 ramdisk Roy S.C. Ho
2001-12-04 19:47 ` Padraig Brady
2001-12-04 20:14 ` Alan Cox
2001-12-05 7:49 ` Christoph Rohland
2001-12-05 7:56 ` Tachino Nobuhiro
2001-12-05 8:23 ` Christoph Rohland
2001-12-05 8:42 ` Tachino Nobuhiro
2001-12-05 13:51 ` Christoph Rohland
2001-12-06 16:37 ` David Gibson
2001-12-06 16:55 ` Alan Cox
2001-12-08 9:53 ` Christoph Rohland [this message]
2001-12-14 5:35 ` David Gibson
2001-12-16 15:34 ` Christoph Rohland
2001-12-17 3:49 ` David Gibson
2001-12-17 7:55 ` Christoph Rohland
2001-12-05 9:37 ` Roy S.C. Ho
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=m3snamhwle.fsf@linux.local \
--to=cr@sap.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=david@gibson.dropbear.id.au \
--cc=linux-kernel@vger.kernel.org \
--cc=padraig@antefacto.com \
--cc=scho1208@yahoo.com \
--cc=tachino@open.nm.fujitsu.co.jp \
/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.