Index: 2-pre1.1/fs/Config.in
--- 2-pre1.1/fs/Config.in Sat, 24 Nov 2001 05:28:08 +1100 kaos (linux-2.5/F/d/27_Config.in 1.1 644)
+++ 2-pre2.1/fs/Config.in Wed, 26 Dec 2001 14:32:39 +1100 kaos (linux-2.5/F/d/27_Config.in 1.2 644)
@@ -45,7 +45,7 @@ if [ "$CONFIG_JFFS2_FS" = "y" -o "$CONFI
fi
tristate 'Compressed ROM file system support' CONFIG_CRAMFS
bool 'Virtual memory file system support (former shm fs)' CONFIG_TMPFS
-tristate 'Simple RAM-based file system support' CONFIG_RAMFS
+define_bool CONFIG_RAMFS y
Why is ramfs forced on?
And why is Al Viro's email address not in CREDITS or MAINTAINERS? We
should have somewhere to complain to ;).
In article <[email protected]>,
Keith Owens <[email protected]> wrote:
>
>Why is ramfs forced on?
Because it's small, and if it wasn't there, we'd have to have the small
"rootfs" anyway (which basically duplicated ramfs functionality).
>And why is Al Viro's email address not in CREDITS or MAINTAINERS? We
>should have somewhere to complain to ;).
He didn't want to be in either file at some point (yes, I asked him),
some day I'll put him in anyway (he's been the effective maintainer of
the VFS interface for the last year or so, regardless of whether he
wants to be in the MAINTAINTERS file or not).
Linus
On Wed, 26 Dec 2001, Keith Owens wrote:
> Index: 2-pre1.1/fs/Config.in
> --- 2-pre1.1/fs/Config.in Sat, 24 Nov 2001 05:28:08 +1100 kaos (linux-2.5/F/d/27_Config.in 1.1 644)
> +++ 2-pre2.1/fs/Config.in Wed, 26 Dec 2001 14:32:39 +1100 kaos (linux-2.5/F/d/27_Config.in 1.2 644)
> @@ -45,7 +45,7 @@ if [ "$CONFIG_JFFS2_FS" = "y" -o "$CONFI
> fi
> tristate 'Compressed ROM file system support' CONFIG_CRAMFS
> bool 'Virtual memory file system support (former shm fs)' CONFIG_TMPFS
> -tristate 'Simple RAM-based file system support' CONFIG_RAMFS
> +define_bool CONFIG_RAMFS y
>
> Why is ramfs forced on?
Because it's always used for rootfs - notice a bunch of crap disappearing
from the end of fs/namespace.c. In principle, we can keep the config item
and make the first DECLARE_FSTYPE in ramfs/inode.c conditional, but that
will only make ramfs invisible - code still needs to be compiled in.
> And why is Al Viro's email address not in CREDITS or MAINTAINERS? We
> should have somewhere to complain to ;).
<shrug> I _do_ read l-k.
> Because it's small, and if it wasn't there, we'd have to have the small
> "rootfs" anyway (which basically duplicated ramfs functionality).
Can ramfs=N longer term actually come back to be "use __init for the RAM
fs functions". That would seem to address any space issues even the most
embedded fanatic has.
Alan
On Wed, Dec 26, 2001 at 03:04:40PM +0000, Alan Cox wrote:
> > Because it's small, and if it wasn't there, we'd have to have the small
> > "rootfs" anyway (which basically duplicated ramfs functionality).
>
> Can ramfs=N longer term actually come back to be "use __init for the RAM
> fs functions". That would seem to address any space issues even the most
> embedded fanatic has.
Nifty idea... We could use __rootfs or similar in the module.
Jeff
On Wed, 26 Dec 2001, Legacy Fishtank wrote:
> On Wed, Dec 26, 2001 at 03:04:40PM +0000, Alan Cox wrote:
> > > Because it's small, and if it wasn't there, we'd have to have the small
> > > "rootfs" anyway (which basically duplicated ramfs functionality).
> >
> > Can ramfs=N longer term actually come back to be "use __init for the RAM
> > fs functions". That would seem to address any space issues even the most
> > embedded fanatic has.
>
> Nifty idea... We could use __rootfs or similar in the module.
Um, folks - rootfs does _not_ go away after you mount final root over it.
Having absolute root always there makes life much simpler in a lot of
places...
What's more, quite a few ramfs methods are good candidates for library
functions, since they are already shared with other filesystems and
number of such cases is going to grow.
On Wed, Dec 26, 2001 at 12:36:09PM -0500, Alexander Viro wrote:
> What's more, quite a few ramfs methods are good candidates for library
> functions, since they are already shared with other filesystems and
> number of such cases is going to grow.
Good point, ext2meta uses the ramfs aops...
Jeff
On Wed, 26 Dec 2001, Alan Cox wrote:
> > Because it's small, and if it wasn't there, we'd have to have the small
> > "rootfs" anyway (which basically duplicated ramfs functionality).
>
> Can ramfs=N longer term actually come back to be "use __init for the RAM
> fs functions". That would seem to address any space issues even the most
> embedded fanatic has.
Hmm.. That might work, but at the same time I suspect that the most
fanatic embedded users are actually the ones that may benefit most from
ramfs in the first place. That was certainly why it came to be..
We'll see. We'll end up using ramfs for the initial init bootup (ie the
"tar.gz->ramfs" stage of bootup), so making it __init may not be practical
for other reasons. We'd have to unload it not after the __init stage, but
after the first root filesystem is unused (which may be later, depending
on what people put in the filesystem).
Linus
Alexander Viro <[email protected]> writes:
> On Wed, 26 Dec 2001, Legacy Fishtank wrote:
>
> > On Wed, Dec 26, 2001 at 03:04:40PM +0000, Alan Cox wrote:
> > > > Because it's small, and if it wasn't there, we'd have to have the small
> > > > "rootfs" anyway (which basically duplicated ramfs functionality).
> > >
> > > Can ramfs=N longer term actually come back to be "use __init for the RAM
> > > fs functions". That would seem to address any space issues even the most
> > > embedded fanatic has.
> >
> > Nifty idea... We could use __rootfs or similar in the module.
>
> Um, folks - rootfs does _not_ go away after you mount final root over it.
> Having absolute root always there makes life much simpler in a lot of
> places...
>
> What's more, quite a few ramfs methods are good candidates for library
> functions, since they are already shared with other filesystems and
> number of such cases is going to grow.
I guess this is o.k. Assuming we get good code sharing between ramfs/rootfs
and shmfs. As those both seem to be always compiled in.
Eric