Initramfs and TMPFS!
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Initramfs and TMPFS!
>> 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Initramfs and TMPFS!
>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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Initramfs and TMPFS!
>>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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Initramfs and TMPFS!
>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 >>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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Initramfs and TMPFS!
>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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Initramfs and TMPFS!
>On Thu, Aug 25, 2005 at 12:35:22AM -0400, [EMAIL PROTECTED] 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Initramfs and TMPFS!
>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%). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Initramfs and TMPFS!
>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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Initramfs and TMPFS!
>On Thu, Aug 25, 2005 at 11:38:49AM -0400, [EMAIL PROTECTED] 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Initramfs and TMPFS!
>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). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Initramfs and TMPFS!
On Fri, Aug 26, 2005 at 12:06:47PM -0700, Chris Wedgwood wrote: > On Thu, Aug 25, 2005 at 09:39:15PM -0400, [EMAIL PROTECTED] wrote: > > > Wouldn't it be better to put overmount_rootfs in initramfs.c > > and call it only if there's a initramfs? > > I don't see what or how that helps. Yes we can shuffle some code > about but the real problem still exists. > > That is is that (by design) the early userspace is unpacked as soon as > possible before all kernel subsystems are up. Overmount_rootfs shouldn't take place until you know for sure the kernel detects an initramfs. I know the patch only has one purpose and you can assume the user is using it just for that, but if the user uses the patched kernel without an initramfs it runs overmount_rootfs anyway. Also, in shmem.c init_tmpfs isn't run because it assumes that overmount_rootfs will be, so if the kernel is being used in a non initramfs way (tmpfs isn't registered). #ifndef CONFIG_EARLYUSERSPACE_ON_TMPFS module_init(init_tmpfs) #endif /* !CONFIG_EARLYUSERSPACE_ON_TMPFS */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Initramfs and TMPFS!
On Fri, Aug 26, 2005 at 01:22:26PM -0700, Chris Wedgwood wrote: > On Fri, Aug 26, 2005 at 08:08:51PM +, Kent Robotti wrote: > > > Overmount_rootfs shouldn't take place until you know for sure the > > kernel detects an initramfs. > > Actually, it was a deliberate decision to *always* overmount after > some discussion with people. Ideally, I don't know why you would want to overmount unless the kernel detects an initramfs. > It's not a clean solution and the overall goals aren't clear here so > it was never submitted for inclusion --- an the fact is 99.9% of users > simply don't need or care for this. I know the patch is just a quick and simple way to use tmpfs for initramfs, and it seems to work. But, it would be nice if were cleaned up for that less than one percent. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Initramfs and TMPFS!
On Fri, Aug 26, 2005 at 05:40:45PM -0700, Chris Wedgwood wrote: > On Fri, Aug 26, 2005 at 09:12:31PM +, Kent Robotti wrote: > > > Ideally, I don't know why you would want to overmount unless the > > kernel detects an initramfs. > > because the rootfs doesn't work the way you think it does. there are > a number of complex and sublte issues > > if you look at the patch it does quite a lot of work because of this The purpose of the patch is to overmount ramfs/rootfs with tmpfs before the compressed cpio archive is unpacked and /init is run. If there's no compressed cpio archive there's no need to overmount with tmpfs, because we're not doing initramfs. That's my understanding of it. > > I know the patch is just a quick and simple way to use tmpfs for > > initramfs, and it seems to work. > > as previously mentioned, there are a number of subtle issues to > consider that are non-obvious > > people are free to do their own patches but the rootfs does not always > work the way you expect it to > > > But, it would be nice if were cleaned up for that less than one > > percent. > > given most people don't need/want this i don't see that happening. > once klibc is merged i might go over this again but until then it > doesn't seem useful Even as it is I find it useful. But, it's only needed because the current initramfs implementation doesn't offer tmpfs as an option. If you had the option of using tmpfs as the initramfs you wouldn't need to do pivot-root or mount-move etc., because you would already be where you wanted. /init could just be a symbolic link to /sbin/init, or it could be some other executable (shell script etc.), but there would be no need to pivot or move root. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Initramfs and TMPFS!
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Initramfs and TMPFS!
On Sat, Aug 27, 2005 at 02:28:17PM -0700, Chris Wedgwood wrote: > How about you do a little research on some things for a bit? The > initramfs code is done the way it is for a good reason. cpio is used > over tar for another good reason. Why don't you do some research on manners? > You are most welcome to disagree and even voice you disagreement, but > there comes a point where you really need to produce some better > arguments. Patches wouldn't hurt either. Are you satisfied ass? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
