public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Re: Initramfs and TMPFS!
@ 2005-08-27  8:19 Kent Robotti
  2005-08-27 21:28 ` Chris Wedgwood
  0 siblings, 1 reply; 48+ messages in thread
From: Kent Robotti @ 2005-08-27  8:19 UTC (permalink / raw)
  To: linux-kernel

   On Fri Aug 26 2005 - 05:33:43 EST, Erik Mouw wrote:
   > I prefer tar because I have more experience with it, and it works.
   >> The kernel people prefer cpio because they have experience with it, it
   >> doesn't need too much code, and it works.
   
I know that experience dosen't come from packing the kernel source,
or the zillion other tar archives on the internet.
   
   > It seems to be the most used archiver in the UNIX world.
   >> You've been told that there are *technical* reasons not to use tar in
   >> the kernel. The kernel developers never cared about what was most used
   >> or what "the market wants", but only about what was *technically*
   >> useful.

I haven't been told that.
   
   >>Did you ever take some time to actually *understand* what ramfs is,
   >>*why* it is used for initramfs, and why you can't use any filesystem
   >>you like for an initramfs?
   
You can use tmpfs and that's sufficient.

You only need one initramfs and it should be tmpfs, but if you
have two make ramfs a little more robust (that word again!).

This is a definition of robust I found on the web:
   Refers to software without bugs that handles abnormal conditions well.
   It is often  said that there is no software package totally bug free.
   Any program can exhibit odd behavior under certain conditions, but a
   robust program will not *lock up* the computer, cause damage to data or
   send the user through an endless chain of dialog boxes without
   purpose.  Whether or not a program can be totally bug free will be
   debated forever.

I'm sure if I gave ramfs a chance it would fit that definition to a tee.
    
   > For one, if you do "dd if=/dev/zero of=foo" on a ramfs the system
   > will lock up.
   >> "Doctor, it hurts when I do this!" "Well, then don't do that."
   >> You found a nice case of "Unix, rope, foot".

I guess you graduated from the Henny Youngman school of coding, the same
school the author of ramfs graduated from.

But seriously, you're obviously a coder/comedian and I hope you don't
confuse the two.

If Windows had that defeatest philosophy where would it be?

Ramfs has a more limited use than tmpfs and that may be sufficient,
because people know its limitations and stay within them, but
that's no reason to pat yourself on the back.

   >>PS: I'm not going to hunt through my linux-kernel mailbox for replies
   >>without proper In-Reply-To and References headers in the hope that I
   >>stumble over a possible reply from you. Any reply without such
   >>headers will most probably not been seen and just ignored.
   
You have to Cc me if you want that.

^ permalink raw reply	[flat|nested] 48+ messages in thread
* Re: Initramfs and TMPFS!
@ 2005-09-03  8:29 Chuck Ebbert
  0 siblings, 0 replies; 48+ messages in thread
From: Chuck Ebbert @ 2005-09-03  8:29 UTC (permalink / raw)
  To: Erik Mouw; +Cc: linux-kernel

In-Reply-To: <20050826102943.GA28640@harddisk-recovery.com>

> Linux-kernel is a very high volume mailing list, and proper use of
> email threading is *vital* to read it: you immediately get all
> references to previous messages, and it makes it easy to skip threads
> you're not interested in 

 Does manually adding the reply header work?

> (nobody except Alan Cox and his gnomes reads
> every message to linux-kernel).

 Some of us use KDE. :-P


__
Chuck

^ permalink raw reply	[flat|nested] 48+ messages in thread
[parent not found: <4Fuuy-6df-11@gated-at.bofh.it>]
* Initramfs and TMPFS!
@ 2005-08-26  6:09 Kent Robotti
  0 siblings, 0 replies; 48+ messages in thread
From: Kent Robotti @ 2005-08-26  6:09 UTC (permalink / raw)
  To: linux-kernel

   >I'm not subscribed, so sorry if this doesn't fall into the original
   >thread. I'm curious as to why the kernel has to include the decoder -
   >why you can't just run a self-extracting executable in an empty
   >initramfs (with a preset capacity if needs be).

The kernel already includes gunzip for itself, so it just needs an
unarchiver (tar or cpio) which should just add a few Kb.

Every self-extracting executable would require the builtin code
to extract itself.

The kernel code to recognize and execute the self-extracting code,
would probably be the same size as an unarchiver (tar or cpio).


^ permalink raw reply	[flat|nested] 48+ messages in thread
* Initramfs and TMPFS!
@ 2005-08-26  1:39 dwilson24
  2005-08-26 19:06 ` Chris Wedgwood
  0 siblings, 1 reply; 48+ messages in thread
From: dwilson24 @ 2005-08-26  1:39 UTC (permalink / raw)
  To: linux-kernel



This is in reference to Chris Wedgwood's patch.

Wouldn't it be better to put overmount_rootfs in initramfs.c
and call it only if there's a initramfs?

		printk(KERN_INFO "checking if image is initramfs...");
		err = unpack_to_rootfs((char *)initrd_start,
			initrd_end - initrd_start, 1);
		if (!err) {
			printk(" it is\n");
#ifdef CONFIG_EARLYUSERSPACE_ON_TMPFS
                        overmount_rootfs();
#endif /* CONFIG_EARLYUSERSPACE_ON_TMPFS */
			unpack_to_rootfs((char *)initrd_start,
				initrd_end - initrd_start, 0);
			free_initrd_mem(initrd_start, initrd_end);
			return;

^ permalink raw reply	[flat|nested] 48+ messages in thread
* Initramfs and TMPFS!
@ 2005-08-25 19:32 dwilson24
  0 siblings, 0 replies; 48+ messages in thread
From: dwilson24 @ 2005-08-25 19:32 UTC (permalink / raw)
  To: linux-kernel


   >I'm not subscribed to the list and I use lynx and a small mda
   >called msmtp, so I know it's awkward (perhaps mostly for me).
   >>People seem to  be  CCing  you, can't you reply to the message you
   >>receive that way? That's how everyone else who doesn't subscribe
   >>gets along...
   >>Anyway, if you insist on sending things manually, you could add the
   >>correct References and/or In-Reply-To headers by had as well.

That free email-address <robotti@godmail.com> doesn't seem to be working,
so I haven't gotten any mail there in awhile.

I have another email address that does work, but I have no interface to it.

I can download mail using fetchmail and read/reply using mutt, perhaps
that would do.

This is the good email-address: <dwilson24@nyc.rr.com>

^ permalink raw reply	[flat|nested] 48+ messages in thread
* Re: Initramfs and TMPFS!
@ 2005-08-25 19:05 Alan Jenkins
  2005-08-26 10:37 ` Erik Mouw
  2005-08-26 19:08 ` Chris Wedgwood
  0 siblings, 2 replies; 48+ messages in thread
From: Alan Jenkins @ 2005-08-25 19:05 UTC (permalink / raw)
  To: linux-kernel

> On Thu, Aug 25, 2005 at 12:32:50AM -0400, robo...@godmail.com wrote: 
> > Right, but it would be nice to have that option if initramfs 
> > using tmpfs becomes part of the kernel. 
> 
> But it's not needed so why add bloat? 

I'm not subscribed, so sorry if this doesn't fall into the original
thread.  I'm curious as to why the kernel has to include the decoder -
why you can't just run a self-extracting executable in an empty
initramfs (with a preset capacity if needs be).

^ permalink raw reply	[flat|nested] 48+ messages in thread
* Initramfs and TMPFS!
@ 2005-08-25 18:23 robotti
  0 siblings, 0 replies; 48+ messages in thread
From: robotti @ 2005-08-25 18:23 UTC (permalink / raw)
  To: linux-kernel


   >On Thu, Aug 25, 2005 at 11:38:49AM -0400, robotti@xxxxxxxxxxx wrote:
   >What if you have a root.cpio.gz that requires 200MB to hold, but you
   >only have 300MB of memory?
   >
   >50% of total memory wouldn't hold it, but 90% etc. would
   >(tmpfs_size=90%).

   >>tmpfs will not help you here. Yes, it can be swapped, but just like
   >>with ramfs you first need to *unpack* the cpio archive before you can
   >>even start the "swapon /dev/hda2" command on it.

I was making a case for a tmpfs_size option if tmpfs is used for a initramfs,
because tmpfs has a default 50% memory limit.

   >>Same with initrd, btw. If the compressed initrd image, plus the
   >>uncompressed image, plus the kernel size are larger than the memory
   >>size, the system will not boot.

Right.

   

^ permalink raw reply	[flat|nested] 48+ messages in thread
* Initramfs and TMPFS!
@ 2005-08-25 18:15 robotti
  2005-08-25 19:10 ` Ian Campbell
  2005-08-26 10:29 ` Erik Mouw
  0 siblings, 2 replies; 48+ messages in thread
From: robotti @ 2005-08-25 18:15 UTC (permalink / raw)
  To: linux-kernel


   >Could you please please pretty please get an RFC compliant mailer that
   >generates  "In-Reply-To" and preferable even "References" headers?
   >Right
   >now every mail you write starts a new thread instead of referencing to
   >the previous one. See http://lkml.org/lkml/2005/8/25/180/ to see what
   >I mean.

I'm not subscribed to the list and I use lynx and a small mda
called msmtp, so I know it's awkward (perhaps mostly for me).

But, that's my setup.

Perhaps if the list had a followup/reply option, I could use that in lynx.

But, the list just seems to be useful for reading purposes.

Perhaps I could access the list through a newsreader and the
replys would be threaded/referenced.

   >Cpio is perhaps as available as tar, but it's not as used as tar.
   >>So? Firefox is as available as IE, but it's not as used as IE. Does
   >>that make IE better?
   
I have no opinion on which one is better.
   
I prefer tar because I have more experience with it, and it works.
   
It seems to be the most used archiver in the UNIX world.
   
   >Unless tar would be inordinately larger than a cpio implementation
   >(I can't imagine, but I'm not a coder!) I would prefer it.
   >>You have been told a couple of times that a tar implementation in
   >>kernel is indeed larger than a cpio implementation. If you're not a
   >>coder, just believe the coders.
   
No one has explicitly told me that. 
   
   >If initramfs replaces the old initrd method it should have something
   >as a filesystem that's robust and inspires confidence like ext2.
   >>The simplicity of ramfs inspires more than enough confidence.
   
   >I know generally an initrd is used to load modules and prepare
   >the installation of a Linux system, so it doesn't require much
   >in a filesystem.
   >>An initramfs can be used to do the same, but doesn't have the overhead
   >>of a block device. IOW: it requires even *less* than an initrd.
   
Right, an initramfs can/should replace the old initrd method, but
it should be comparable and have a filesystem like tmpfs as an option.
   
The old initrd method could use any filesystem for the initrd
that the kernel could support, but now with initramfs all you
have is ramfs.
    
If you add tmpfs to initramfs you make initramfs comparable enough
(on the filesystem level) to replace the old initrd method.
   
Initramfs is already ahead of the old initrd method on other levels.
     
   >But, it can also be used to hold and run a complete Linux system,
   >so a more robust filesystem (tmpfs) is useful.
   >>What makes you think tmpfs is more robust than ramfs? What do you mean
   >>with a "robust filesystem"?

I've used tmpfs and ramfs, so it's based on experience.

I'm sure someone could give you a more technical answer, but if
you're a coder you would probably already know.

For one, if you do "dd if=/dev/zero of=foo" on a ramfs the system
will lock up.

^ permalink raw reply	[flat|nested] 48+ messages in thread
* Initramfs and TMPFS!
@ 2005-08-25 15:38 robotti
  2005-08-25 16:00 ` Erik Mouw
  2005-08-26 19:10 ` Chris Wedgwood
  0 siblings, 2 replies; 48+ messages in thread
From: robotti @ 2005-08-25 15:38 UTC (permalink / raw)
  To: linux-kernel


   >Right, but it would be nice to have that option if initramfs
   >using tmpfs becomes part of the kernel.
   >>But it's not needed so why add bloat?

A 'tmpfs_size' option seems to just make sense given the fact that
the mount program has a 'size' option for tmpfs.

It makes sense if tmpfs becomes am initramfs option. 

It's one less thing to do in an init script.

What if you have a root.cpio.gz that requires 200MB to hold, but you
only have 300MB of memory?

50% of total memory wouldn't hold it, but 90% etc. would (tmpfs_size=90%).
 

^ permalink raw reply	[flat|nested] 48+ messages in thread
* Initramfs and TMPFS!
@ 2005-08-25 15:34 robotti
  2005-08-25 15:54 ` Erik Mouw
  2005-08-26 15:03 ` Horst von Brand
  0 siblings, 2 replies; 48+ messages in thread
From: robotti @ 2005-08-25 15:34 UTC (permalink / raw)
  To: linux-kernel


   >On Thu, Aug 25, 2005 at 12:35:22AM -0400, robotti@xxxxxxxxxxx wrote:
   >I don't know, because tar is probably more widely used and
   >consequently people are more familiar with how to use it.
   >>As I said before, the cpio format is cleaner/easier to parse in the
   >>kernel. Everyone has cpio probably so using tar isn't necessary.

Cpio is perhaps as available as tar, but it's not as used as tar.

Unless tar would be inordinately larger than a cpio implementation
(I can't imagine, but I'm not a coder!) I would prefer it.
 
   >But, that is not as important as having the option of using tmpfs
   >as the initramfs.
   >>Well, it's not clean that we really want this either. I have some
   >>niche needs for it but I suspect most people will never use such an
   >>option.

If initramfs replaces the old initrd method it should have something
as a filesystem that's robust and inspires confidence like ext2.

I know generally an initrd is used to load modules and prepare
the installation of a Linux system, so it doesn't require much
in a filesystem.

But, it can also be used to hold and run a complete Linux system,
so a more robust filesystem (tmpfs) is useful. 

^ permalink raw reply	[flat|nested] 48+ messages in thread
* Initramfs and TMPFS!
@ 2005-08-25  4:35 robotti
  2005-08-25 13:49 ` Chris Wedgwood
  0 siblings, 1 reply; 48+ messages in thread
From: robotti @ 2005-08-25  4:35 UTC (permalink / raw)
  To: linux-kernel

   >Also, tar should be an option instead of cpio for the archiver,
   >because tar is more widely used.
   >>pretty much everyone will have cpio and it's format is much
   >>simpler/cleaner to deal with
   >>if we want vastly more complex early-userspace semantics i think we
   >>need to carefully decide what is needed and how to put as much of that
   >>logic into userspace rather than hacking this much more in the kernel
   >>for fear of breaking things in subtle ways

I don't know, because tar is probably more widely used and
consequently people are more familiar with how to use it.

But, that is not as important as having the option of using tmpfs
as the initramfs.

^ permalink raw reply	[flat|nested] 48+ messages in thread
* Initramfs and TMPFS!
@ 2005-08-25  4:32 robotti
  2005-08-25 13:47 ` Chris Wedgwood
  0 siblings, 1 reply; 48+ messages in thread
From: robotti @ 2005-08-25  4:32 UTC (permalink / raw)
  To: linux-kernel


   >It uses 50% of total memory for tmpfs, but it would be nice to have
   >an option (tmpfs_size=90% etc.) that you could pass to the kernel.
   >>that's just because of the tmpfs default; you can remount to change
   >>that if it's not suitable once your up and running in your
   >>init-scripts or whatever
   
Right, but it would be nice to have that option if initramfs
using tmpfs becomes part of the kernel.
   
   >You need to add this to init/main.c for it to compile.
   >#include <asm/uaccess.h>
   >>hmm... really? i'll rediff it at some point and test it maybe. i
   >>really don't like the explicity shm init though, i'd like to think of
   >>a cleaner way to do that

You get this error without it.   
   init/main.c: In function `overmount_rootfs':
init/main.c:663: warning: implicit declaration of function `get_fs'
init/main.c:663: error: incompatible types in assignment
init/main.c:664: warning: implicit declaration of function `set_fs'
init/main.c:664: error: `KERNEL_DS' undeclared (first use in this function)
init/main.c:664: error: (Each undeclared identifier is reported only once
init/main.c:664: error: for each function it appears in.)
make[1]: *** [init/main.o] Error 1
make: *** [init] Error 2
   

^ permalink raw reply	[flat|nested] 48+ messages in thread
* Initramfs and TMPFS!
@ 2005-08-24 22:41 robotti
  2005-08-25  3:12 ` Chris Wedgwood
  0 siblings, 1 reply; 48+ messages in thread
From: robotti @ 2005-08-24 22:41 UTC (permalink / raw)
  To: linux-kernel


   >>On Wed, Aug 24, 2005 at 04:52:37PM -0400, Wakko Warner wrote:
   >>Care to send me the patch?
   >Heh. Not really as I don't really know if people should be using it
   >in it's current state --- the shmem init is very very hacky and I have
   >other changes I've not had a chance to do.
   >Anyhow, here is an older version of it. It's from some old internal
   >embedded tree but should be trivial to shoehorn into anything recent.
   >If people really do like or want this I would like to know and maybe
   >something more elegant can be worked out.

I tried it with kernel 2.6.13-rc5 and it seems to work.

It uses 50% of total memory for tmpfs, but it would be nice to have
an option (tmpfs_size=90% etc.) that you could pass to the kernel.

You need to add this to init/main.c for it to compile.
#include <asm/uaccess.h>

^ permalink raw reply	[flat|nested] 48+ messages in thread
* Initramfs and TMPFS!
@ 2005-08-24  3:15 robotti
  0 siblings, 0 replies; 48+ messages in thread
From: robotti @ 2005-08-24  3:15 UTC (permalink / raw)
  To: linux-kernel


   >I have a path for initramfs to use tmpfs. It's sorta hacky so I never
   >submitted it and solves a niche problem for embedded people.
   >Ultimately we might one day still want to change how we initialize the
   >early userspace (Al suggesting a reasomably nice way to move the
   >decompressor(s) to userspace for example) so I don't feel there is a
   >compelling reason to do more than cleanups in this area right now.

I found that there is a patch that does what I suggested, but it needs
to be updated to support the latest 2.6 kernel.

   http://lwn.net/Articles/14394/

Dave Cinege's patch.
http://ftp.psychosis.com/linux/initrd-dyn/kernelpatches/2.5.45/initrd_dynamic-2.5.45.diff.gz

If you point me to your patch, I'll try it.

^ permalink raw reply	[flat|nested] 48+ messages in thread
* Initramfs and TMPFS!
@ 2005-08-23 22:05 robotti
  2005-08-24  2:57 ` Chris Wedgwood
  0 siblings, 1 reply; 48+ messages in thread
From: robotti @ 2005-08-23 22:05 UTC (permalink / raw)
  To: linux-kernel


   >> Why doesn't initramfs use tmpfs instead of ramfs, because
   >> tmpfs is more robust?
   >>
   >> I know tmpfs is larger, but at least it should be an option.
   >>
   >> Also, tar should be an option instead of cpio for the archiver,
   >> because tar is more widely used.
   >You forgot to attach your patch to your email.
   >OG.

I'm not a coder.

I was just making a suggestion to whoever it may concern, because
I think it would extend the usefullness of initramfs.

^ permalink raw reply	[flat|nested] 48+ messages in thread
* Initramfs and TMPFS!
@ 2005-08-23 21:16 robotti
  2005-08-23 21:24 ` Olivier Galibert
  2005-08-25  3:14 ` Chris Wedgwood
  0 siblings, 2 replies; 48+ messages in thread
From: robotti @ 2005-08-23 21:16 UTC (permalink / raw)
  To: linux-kernel



Why doesn't initramfs use tmpfs instead of ramfs, because
tmpfs is more robust?

I know tmpfs is larger, but at least it should be an option.

Also, tar should be an option instead of cpio for the archiver,
because tar is more widely used.


^ permalink raw reply	[flat|nested] 48+ messages in thread
end of thread, other threads:[~2005-09-03  8:31 UTC | newest]

Thread overview: 48+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-08-27  8:19 Initramfs and TMPFS! Kent Robotti
2005-08-27 21:28 ` Chris Wedgwood
2005-08-27 21:42   ` Lee Revell
2005-08-27 22:45   ` Kent Robotti
2005-08-27 22:42     ` David Weinehall
2005-08-27 22:57     ` Patrick McFarland
2005-08-27 23:38     ` Chris Wedgwood
2005-08-27 23:41   ` Alistair John Strachan
2005-08-28  0:21     ` Patrick McFarland
2005-08-28  5:36     ` Willy Tarreau
  -- strict thread matches above, loose matches on Subject: below --
2005-09-03  8:29 Chuck Ebbert
     [not found] <4Fuuy-6df-11@gated-at.bofh.it>
     [not found] ` <4FJMZ-1YX-17@gated-at.bofh.it>
2005-08-26 15:49   ` Bodo Eggert
2005-08-26  6:09 Kent Robotti
2005-08-26  1:39 dwilson24
2005-08-26 19:06 ` Chris Wedgwood
2005-08-26 20:08   ` Kent Robotti
2005-08-26 20:22     ` Chris Wedgwood
2005-08-26 21:34       ` Kent Robotti
     [not found]       ` <20050826211231.GA957@Linux.nyc.rr.com>
     [not found]         ` <20050827004045.GA17686@taniwha.stupidest.org>
2005-08-27  3:21           ` Kent Robotti
2005-08-27  4:11             ` Chris Wedgwood
2005-08-25 19:32 dwilson24
2005-08-25 19:05 Alan Jenkins
2005-08-26 10:37 ` Erik Mouw
2005-08-26 19:08 ` Chris Wedgwood
2005-08-25 18:23 robotti
2005-08-25 18:15 robotti
2005-08-25 19:10 ` Ian Campbell
2005-08-26 10:29 ` Erik Mouw
2005-08-25 15:38 robotti
2005-08-25 16:00 ` Erik Mouw
2005-08-26 19:10 ` Chris Wedgwood
2005-08-25 15:34 robotti
2005-08-25 15:54 ` Erik Mouw
2005-08-26 15:03 ` Horst von Brand
2005-08-25  4:35 robotti
2005-08-25 13:49 ` Chris Wedgwood
2005-08-25  4:32 robotti
2005-08-25 13:47 ` Chris Wedgwood
2005-08-24 22:41 robotti
2005-08-25  3:12 ` Chris Wedgwood
2005-08-24  3:15 robotti
2005-08-23 22:05 robotti
2005-08-24  2:57 ` Chris Wedgwood
2005-08-24 20:52   ` Wakko Warner
2005-08-24 20:59     ` Chris Wedgwood
2005-08-23 21:16 robotti
2005-08-23 21:24 ` Olivier Galibert
2005-08-25  3:14 ` Chris Wedgwood

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox