Re: Initramfs and TMPFS!
In-Reply-To: <[EMAIL PROTECTED]> > 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 - 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 Sun, Aug 28, 2005 at 12:41:08AM +0100, Alistair John Strachan wrote: > On Saturday 27 August 2005 22:28, Chris Wedgwood wrote: > > On Sat, Aug 27, 2005 at 08:19:18AM +, Kent Robotti wrote: > > > I know that experience dosen't come from packing the kernel source, > > > or the zillion other tar archives on the internet. > > > > Are you deliberately trying to be annoying? Let me guess: > > > > - your under 25 years of age, probably in high school or not far > > out of it > > > > No offence Chris, but not everybody under 25 is an asshole. Perhaps, but you must agree that 9 months before birth, we all have been very close to an asshole :-) Sorry, could not resist. Willy - 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 Saturday 27 August 2005 07:41 pm, Alistair John Strachan wrote: > No offence Chris, but not everybody under 25 is an asshole. Get real. We have two things colliding here: 1) People in the FOSS community often are assholes 2) People under 25 often are assholes ... ergo, people in the FOSS community and under 25 are an impossibly vast majority of assholes. I, for one, welcome our new 25 year old FOSS overlords. -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 pgpvCRlmcqGdF.pgp Description: PGP signature
Re: Initramfs and TMPFS!
On Saturday 27 August 2005 22:28, Chris Wedgwood wrote: > On Sat, Aug 27, 2005 at 08:19:18AM +, Kent Robotti wrote: > > I know that experience dosen't come from packing the kernel source, > > or the zillion other tar archives on the internet. > > Are you deliberately trying to be annoying? Let me guess: > > - your under 25 years of age, probably in high school or not far > out of it > No offence Chris, but not everybody under 25 is an asshole. [snip] > > - you're very interesting in real-time patches. linux should > clearly have all real-time stuff merged. second to your interest > in realtime is probably something like selinux As Lee mentioned elsewhere, Ingo's work is essential for many of us in a professional context. Disparaging comments about, well, useful patches are unnecessary here. [snip] > Please. > Kent is sure a troll, but don't let him or any other person with no technical understanding of the issues annoy you. Also is it just me or did LKML get a series of disconnected rubbish on this thread? Please, don't add mailing lists to CC without a good reason, especially not if it's this kind of rubbish. -- Cheers, Alistair. 'No sense being pessimistic, it probably wouldn't work anyway.' Third year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - 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 10:45:55PM +, Kent Robotti wrote: > Why don't you do some research on manners? It was (an obvious) troll. Don't take it so seriously. Besides, deep deep down I really am a terrible person. - 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 Saturday 27 August 2005 06:45 pm, Kent Robotti wrote: > Are you satisfied ass? ... said the troll. -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 pgpE93ut8iya8.pgp Description: PGP signature
Re: Initramfs and TMPFS!
On Sat, Aug 27, 2005 at 10:45:55PM +, Kent Robotti wrote: > 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? Pot. Kettle. Black. [snip] Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/ - 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/
Re: Initramfs and TMPFS!
On Sat, 2005-08-27 at 14:28 -0700, Chris Wedgwood wrote: > - you're very interesting in real-time patches. linux should > clearly have all real-time stuff merged. second to your interest > in realtime is probably something like selinux Please don't lump the -rt kernel people in with the Gentoo ricer crowd. Most people running those patches really do need them. Lee - 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 08:19:18AM +, Kent Robotti wrote: > I know that experience dosen't come from packing the kernel source, > or the zillion other tar archives on the internet. Are you deliberately trying to be annoying? Let me guess: - your under 25 years of age, probably in high school or not far out of it - you have a stupid oversized wanky computer case with neon lighting and useless analog dials and what not. you might have even overclocked it - you've run windows most of your live - you probably run gentoo now. you like the feeling of having everything optimized for your exact system; the addition 0.25% speed increase more than offsets the fact everything is crappy and crashes all the time - you run reiserfs, you probably can't wait till reiser4 is merged so you can run that - you're very interesting in real-time patches. linux should clearly have all real-time stuff merged. second to your interest in realtime is probably something like selinux - if you drive a car, it has extra spoilers added and you've replaced the steering wheel with something from MOMO - you 'friends' are worried you'll die a virgin Please. 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. 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. - 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 03:21:27AM +, Kent Robotti wrote: > The purpose of the patch is to overmount ramfs/rootfs with tmpfs before > the compressed cpio archive is unpacked and /init is run. yes and no there are people who want the overmount even without cpio decompression > But, it's only needed because the current initramfs implementation > doesn't offer tmpfs as an option. tmpfs isn't initialized early enough; i've hacked around this but a cleaner solution is needed > /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. pivot is evil, it probably should be depricated - 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 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 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. 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. - 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 Thu, Aug 25, 2005 at 08:05:32PM +0100, Alan Jenkins wrote: > 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). You could do tht right now if you wished. We just support decompression in the kernel because it's not overly painful to do so (the code exists and works fairly well for the most part). The code to do so isn't ver large and it's marked __init too (well, it should be). - 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 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? then it won't work with nay of the schemes you've suggested > 50% of total memory wouldn't hold it, but 90% etc. would (tmpfs_size=90%). no, actually it won't - 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 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. - 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!
Erik Mouw <[EMAIL PROTECTED]> wrote: > On Thu, Aug 25, 2005 at 02:15:13PM -0400, [EMAIL PROTECTED] wrote: >> 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". It's a case of going into the mountains wearing sandals and carrying the mountain boots in your backpack knowing you should wear them (at least if you read the hidden documentation. If you can leave the sandals at home, you should do that (they are of no use there), but the patch from this(?) thread will just make you change shoes after leaving the house and carry the sandals in the backpack, which could easily be done in userspace (provided you've enough RAM). The real patch would teach how to tie the bootstraps of tmpfs before leaving the house. -- Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF verbreiteten Lügen zu sabotieren. - 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!
[EMAIL PROTECTED] wrote: >>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. There are literaly dozens of "tar" formats around, cpio is much more standardized (and simpler). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - 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 Thu, Aug 25, 2005 at 08:05:32PM +0100, Alan Jenkins wrote: > > On Thu, Aug 25, 2005 at 12:32:50AM -0400, [EMAIL PROTECTED] 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). How would that help? It's still a decoder in the kernel, so why not use one that's well tested instead of using whatever the archive thinks is good? Also remember the code has to be cross platform: an in-kernel decoder will just work on any platform, a self-extracting binary will probably only work on one platform. Besides, initramfs was made to set up userland. A self-extracting binary creates a chicken-and-egg problem: when run it will create a userland, but in order to be run it needs a userland. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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 Thu, Aug 25, 2005 at 02:15:13PM -0400, [EMAIL PROTECTED] wrote: > >>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). No, it's mostly awkward for the people reading linux-kernel. 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 (nobody except Alan Cox and his gnomes reads every message to linux-kernel). If you're not subscribed, the normal way is to: - Ask to be Cc'ed (that usually happens anyway). - Reply to the sender, the list, and everybody else in the Cc list. - Keep In-Reply-To and References headers so the other subscribers know what to read and what not. > But, that's my setup. It would never occur to me to use something as inappropriate as a web browser as a mail client... > Perhaps if the list had a followup/reply option, I could use that in lynx. It hasn't for good reasons. Read the LKML FAQ at http://www.tux.org/lkml/ . > 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. Please do so. It will certainly help you to get more/different replies. >>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. The kernel people prefer cpio because they have experience with it, it doesn't need too much code, and it works. > 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 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. Initramfs using ramfs *is* comparable and it *has* a filesystem. > 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. 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? > If you add tmpfs to initramfs you make initramfs comparable enough > (on the filesystem level) to replace the old initrd method. Read the code, ramfs *is* comparable to the old initrd method, and tmpfs is the same as ramfs with the difference that its pages can be swapped out. > Initramfs is already ahead of the old initrd method on other levels. It is, but mostly because it makes the kernel boot procedure so much easier and removes a lot of special cases in the code. >>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. You have used both, so why is tmpfs a "robust filesystem" and ramfs not? Again, what is your definition of a "robust filesystem"? > 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. "Doctor, it hurts when I do this!" "Well, then don't do that." You found a nice case of "Unix, rope, foot". Erik 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. -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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.ke
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/
Initramfs and TMPFS!
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;
-
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 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 <[EMAIL PROTECTED]> 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: <[EMAIL PROTECTED]> - 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 Thu, Aug 25, 2005 at 12:32:50AM -0400, [EMAIL PROTECTED] 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). - 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 Thu, 2005-08-25 at 14:15 -0400, [EMAIL PROTECTED] wrote: >>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). 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. Ian. -- Ian Campbell Experience is the worst teacher. It always gives the test first and the instruction afterward. signature.asc Description: This is a digitally signed message part
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!
>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/
Re: 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. 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. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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!
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. On Thu, Aug 25, 2005 at 11:34:01AM -0400, [EMAIL PROTECTED] wrote: > >>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. So? Firefox is as available as IE, but it's not as used as IE. Does that make IE better? > 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. > 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. > 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"? Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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!
>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/
Re: 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. > 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. - 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 Thu, Aug 25, 2005 at 12:32:50AM -0400, [EMAIL PROTECTED] 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? - 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!
>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/
Re: Initramfs and TMPFS!
On Tue, Aug 23, 2005 at 05:16:05PM -0400, [EMAIL PROTECTED] wrote: > 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 - 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 Wed, Aug 24, 2005 at 06:41:26PM -0400, [EMAIL PROTECTED] wrote: > I tried it with kernel 2.6.13-rc5 and it seems to work. it should yes > 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 > 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 - 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/
Re: 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.
Index: linux/init/main.c
===
--- linux/init/main.c (revision 51)
+++ linux/init/main.c (working copy)
@@ -689,6 +689,49 @@
#endif
}
+/* If we want the rootfs on initramfs so we mount initramfs over the
+ * rootfs before we unpack it. The little dance we do by creating a
+ * pivot point and moving the root to that is in fact necessary
+ * because lookups of "." don't resolve mountpoints.
+ */
+static inline void __init overmount_rootfs(void)
+{
+#ifdef CONFIG_EARLYUSERSPACE_ON_TMPFS
+ int init_tmpfs(void);
+ int (*initfunc)(void) = init_tmpfs;
+ mm_segment_t oldfs;
+ char pivot[] = "/pivot";
+
+ /* Explicitly go and init the overmount fs early (long-term
+* the need for this will probably go away. */
+
+ if (initfunc())
+ goto err;
+
+ oldfs = get_fs();
+ set_fs(KERNEL_DS);
+
+ if (sys_mkdir(pivot, 0700) < 0)
+ goto err;
+ if (sys_mount("tmpfs", pivot, "tmpfs", 0, NULL))
+ goto err;
+
+ /* Below here errors are unlikely and icky to deal with. */
+ sys_chdir(pivot);
+ sys_mount(".", "/", NULL, MS_MOVE, NULL);
+ sys_chdir(".");
+ sys_chroot(".");
+ printk(KERN_INFO "Overmounted tmpfs\n");
+ goto out;
+
+ err:
+ printk(KERN_ERR "Overmount error\n");
+
+ out:
+ set_fs(oldfs);
+#endif /* CONFIG_EARLYUSERSPACE_ON_TMPFS */
+}
+
static int init(void * unused)
{
lock_kernel();
@@ -715,6 +758,7 @@
* Do this before initcalls, because some drivers want to access
* firmware files.
*/
+ overmount_rootfs();
populate_rootfs();
do_basic_setup();
Index: linux/fs/Kconfig
===
--- linux/fs/Kconfig(revision 51)
+++ linux/fs/Kconfig(working copy)
@@ -951,6 +951,18 @@
If you are not using a security module that requires using
extended attributes for file security labels, say N.
+config EARLYUSERSPACE_ON_TMPFS
+ bool "Unpack the early userspace onto tmpfs"
+ depends TMPFS
+ default y
+ help
+ Use this to have your early userspace placed (decompressed)
+ onto tmpfs as opposed ramfs. This will allow you to
+ restrict the size of your root-filesystem and it will also
+ be swappable.
+
+ If unsure, say Y.
+
config HUGETLBFS
bool "HugeTLB file system support"
depends X86 || IA64 || PPC64 || SPARC64 || SUPERH || X86_64 || BROKEN
Index: linux/mm/shmem.c
===
--- linux/mm/shmem.c(revision 51)
+++ linux/mm/shmem.c(working copy)
@@ -2206,7 +2206,7 @@
};
static struct vfsmount *shm_mnt;
-static int __init init_tmpfs(void)
+int __init init_tmpfs(void)
{
int error;
@@ -2239,7 +2239,12 @@
shm_mnt = ERR_PTR(error);
return error;
}
+/* Don't do this if we are calling it early explicity */
+#ifndef CONFIG_EARLYUSERSPACE_ON_TMPFS
+/* Iff CONFIG_EARLYUSERSPACE_ON_TMPFS is set then we will interpose
+ * ramfs so this will get called explicitly and early */
module_init(init_tmpfs)
+#endif /* !CONFIG_EARLYUSERSPACE_ON_TMPFS */
/*
* shmem_file_setup - get an unlinked file living in 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!
Chris Wedgwood wrote: > 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. Care to send me the patch? -- Lab tests show that use of micro$oft causes cancer in lab animals - 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/
Re: Initramfs and TMPFS!
On Tue, Aug 23, 2005 at 06:05:47PM -0400, [EMAIL PROTECTED] wrote: > I was just making a suggestion to whoever it may concern, because I > think it would extend the usefullness of initramfs. 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. - 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/
Re: Initramfs and TMPFS!
On Tue, Aug 23, 2005 at 05:16:05PM -0400, [EMAIL PROTECTED] wrote: > 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. - 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. - 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/
