Re: [PATCH] rootfs (part 1)
Hi Alan, On Thu, 17 May 2001, Alan Cox wrote: > I think you have a major tool problem. > > bash-2.04$ size mm/shmem.o >text data bss dec hex filename >7422 572 079941f3a mm/shmem.o > bash-2.04$ size fs/ramfs/ramfs.o >text data bss dec hex filename >3185 368 03553 de1 fs/ramfs/ramfs.o > > Never trust ls -l size for binaries, its very very unrelated. > > So ramfs is 3553 bytes, shmem.o in total is 8K on current -ac. But you cannot disable shmem.o totally. That's my whole point in the discussion. Why add something what is mostly included in the kernel already? You have to compare shmem with tmpfs against shmem w/o it: textdata bss dec hex filename 3398 376 03774 ebe fs/ramfs/ramfs.o 5150 484 056341602 mm/shmem.o 9174 636 098102652 mm/shmem.o+tmpfs So tmpfs is 400 Bytes bigger than ramfs. If you add the correct timestamp handling the difference will go down further. And we gain functionality, don't we? Greetings Christoph - 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: [PATCH] rootfs (part 1)
Hi Alan, On Thu, 17 May 2001, Alan Cox wrote: I think you have a major tool problem. bash-2.04$ size mm/shmem.o text data bss dec hex filename 7422 572 079941f3a mm/shmem.o bash-2.04$ size fs/ramfs/ramfs.o text data bss dec hex filename 3185 368 03553 de1 fs/ramfs/ramfs.o Never trust ls -l size for binaries, its very very unrelated. So ramfs is 3553 bytes, shmem.o in total is 8K on current -ac. But you cannot disable shmem.o totally. That's my whole point in the discussion. Why add something what is mostly included in the kernel already? You have to compare shmem with tmpfs against shmem w/o it: textdata bss dec hex filename 3398 376 03774 ebe fs/ramfs/ramfs.o 5150 484 056341602 mm/shmem.o 9174 636 098102652 mm/shmem.o+tmpfs So tmpfs is 400 Bytes bigger than ramfs. If you add the correct timestamp handling the difference will go down further. And we gain functionality, don't we? Greetings Christoph - 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: [PATCH] rootfs (part 1)
On Thu, 17 May 2001, Alan Cox wrote: > > Linus, patch is the first chunk of rootfs stuff. I've tried to > > get it as small as possible - all it does is addition of absolute root > > on ramfs and necessary changes to mount_root/change_root/sys_pivot_root > > and follow_dotdot. Real root is mounted atop of the "absolute" one. > > Surely this is getting right into 2.5 stuff. Maybe. I still think that it's local enough to be tolerable in 2.4, but postponing it until 2.5 is not a big deal. I'll put that (and the rest of rootfs stuff) on anonftp and post CFT. I'd appreciate review of that code once the splitup is done, if you have time for 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: [PATCH] rootfs (part 1)
> cr:/speicher/src/u4ac9 $ ls -l mm/shmem.o* > -rw-r--r--1 cr users 154652 Mai 16 19:27 mm/shmem.o-tmpfs > -rw-r--r--1 cr users 180764 Mai 16 19:24 mm/shmem.o+tmpfs > cr:/speicher/src/u4ac9 $ ls -l fs/ramfs/ramfs.o > -rw-r--r--1 cr users 141452 Mai 16 19:27 fs/ramfs/ramfs.o > > So CONFIG_TMPFS adds 26k and ramfs 140k. I think you have a major tool problem. bash-2.04$ size mm/shmem.o textdata bss dec hex filename 7422 572 079941f3a mm/shmem.o bash-2.04$ size fs/ramfs/ramfs.o textdata bss dec hex filename 3185 368 03553 de1 fs/ramfs/ramfs.o Never trust ls -l size for binaries, its very very unrelated. So ramfs is 3553 bytes, shmem.o in total is 8K on current -ac. - 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: [PATCH] rootfs (part 1)
> Why do you use ramfs? Most of it is duplicated in tmpfs and ramfs is a > minimal _example_ fs. There was some agreement that this should stay > so. I think ramfs is an incredibly flawed example right now - precisely because it has no error cases. ramfs with the size limiting is a brilliant fs for embedded/pda work as well as an example that shows error paths - 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: [PATCH] rootfs (part 1)
> Linus, patch is the first chunk of rootfs stuff. I've tried to > get it as small as possible - all it does is addition of absolute root > on ramfs and necessary changes to mount_root/change_root/sys_pivot_root > and follow_dotdot. Real root is mounted atop of the "absolute" one. Surely this is getting right into 2.5 stuff. - 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: [PATCH] rootfs (part 1)
On Wed, 16 May 2001, H. Peter Anvin wrote: > Alexander Viro wrote: > > > > In full variant of patch I don't _have_ mount_root(9). It's done by > > mount(2). Period. Initrd or not. Notice that rootfs stays absolute root > > forever - it's much more convenient for fs/super.c, since you can get rid > > of many kludges that way. So I'm not too happy about populating rootfs with > > tons of files. BTW, loading initrd is done by open(2), read(2) and write(2) - > > none of this fake struct file business anymore. > > > > OK, I see what you're doing now. However, I'm confused what you mean > with "rootfs stays absolute root forever" -- does that mean that you > mount the new root on top of /, and so the rootfs remains in the system > never to be reclaimed, as opposed to pivot_root-ing it? Yes. Pivot_root works, all right, but it rotates (your process' root, old, new). So it works in chroot correctly now. And since we chroot out of the absolute root when we mount initrd (or final root, for that matter) any setup that used pivot_root keeps working as it did. As for "never to be reclaimed"... Let's see: 1 struct super_block 1 struct vfsmount couple of struct dentry couple of struct inode (for values of couple from 1 to 4; we can reduce it to 1 but I didn't bother with that; all it takes is a couple of calls of sys_rmdir()/sys_unlink()). Compared to the amount of space we free in .code of fs/super.c it's noise. - 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: [PATCH] rootfs (part 1)
Alexander Viro wrote: > > In full variant of patch I don't _have_ mount_root(9). It's done by > mount(2). Period. Initrd or not. Notice that rootfs stays absolute root > forever - it's much more convenient for fs/super.c, since you can get rid > of many kludges that way. So I'm not too happy about populating rootfs with > tons of files. BTW, loading initrd is done by open(2), read(2) and write(2) - > none of this fake struct file business anymore. > OK, I see what you're doing now. However, I'm confused what you mean with "rootfs stays absolute root forever" -- does that mean that you mount the new root on top of /, and so the rootfs remains in the system never to be reclaimed, as opposed to pivot_root-ing it? -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - 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: [PATCH] rootfs (part 1)
On 16 May 2001, H. Peter Anvin wrote: > Followup to: <[EMAIL PROTECTED]> > By author:Alexander Viro <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > Well, since all I actually use in the full variant of patch is sys_mknod(), > > sys_chdir() and sys_mkdir()... IMO tmpfs is an overkill here. Maybe we > > really need minimal rootfs in the kernel (no regular files) and let > > ramfs, tmpfs, whatever-device-fs use it as a library. > > > > One thing that I thought was really spiffy was someone who had done > patches to populate a ramfs from a tarball loaded via the initrd > bootloader protocol... call it "initial ramfs." It allowed a whole > lot of cleanup -- the "initrd" isn't magic anymore (instead use > pivot_root), and it gets rid of the rd stuff. At the same time it > does allow the full flexibility of a fullblown filesystem that can be > populated with arbitrary contents. In full variant of patch I don't _have_ mount_root(9). It's done by mount(2). Period. Initrd or not. Notice that rootfs stays absolute root forever - it's much more convenient for fs/super.c, since you can get rid of many kludges that way. So I'm not too happy about populating rootfs with tons of files. BTW, loading initrd is done by open(2), read(2) and write(2) - none of this fake struct file business anymore. So late-boot stuff (mounting root, unpacking initrd, mounting devfs if asked to, loading initrd from floppies, moving initrd around - the whole whorehouse) is actually done by sane, normal system calls. And it's very easy to expand - I refused to apply any fancy patches simply because I wanted 100% compatibility with all existing boot setups, no matter how silly they are. If behaviour is absent in Linus' tree - sorry. However, playing with that stuff becomes much easier - essentially it's a userland code. You have an empty, writable fs, your root and cwd are on it, you can do any system calls you want. So if you want this untar-into-ramfs - well, more power to you. I'd recommend to use a separate instance of ramfs for that, though, so that you could easily get rid of it afterwards. Again, at that point you have normal userland environment, so doing whatever you want to do doesn't require any kernel-specific stuff. Write as if you were adding your code to the beginning of /sbin/init. - 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: [PATCH] rootfs (part 1)
Followup to: <[EMAIL PROTECTED]> By author:Alexander Viro <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > Well, since all I actually use in the full variant of patch is sys_mknod(), > sys_chdir() and sys_mkdir()... IMO tmpfs is an overkill here. Maybe we > really need minimal rootfs in the kernel (no regular files) and let > ramfs, tmpfs, whatever-device-fs use it as a library. > One thing that I thought was really spiffy was someone who had done patches to populate a ramfs from a tarball loaded via the initrd bootloader protocol... call it "initial ramfs." It allowed a whole lot of cleanup -- the "initrd" isn't magic anymore (instead use pivot_root), and it gets rid of the rd stuff. At the same time it does allow the full flexibility of a fullblown filesystem that can be populated with arbitrary contents. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - 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: [PATCH] rootfs (part 1)
Hi Alexander, On Wed, 16 May 2001, Alexander Viro wrote: > Because what I need is an absolute minimum. Heck, I don't even use > regular files (in the full variant of patch, that is). They might > become useful, but I can live with mkdir() and mknod(). So what about adding shmem_mknod and shmem_mkdir to the core shmem.c part? They are now under CONFIG_TMPFS but are only ~20 lines of code. Greetings Christoph - 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: [PATCH] rootfs (part 1)
Hi Linus, On Wed, 16 May 2001, Linus Torvalds wrote: > > On 16 May 2001, Christoph Rohland wrote: >> >> cr:/speicher/src/u4ac9 $ ls -l mm/shmem.o* >> -rw-r--r--1 cr users 154652 Mai 16 19:27 mm/shmem.o-tmpfs >> -rw-r--r--1 cr users 180764 Mai 16 19:24 mm/shmem.o+tmpfs >> cr:/speicher/src/u4ac9 $ ls -l fs/ramfs/ramfs.o >> -rw-r--r--1 cr users 141452 Mai 16 19:27 fs/ramfs/ramfs.o >> >> So CONFIG_TMPFS adds 26k and ramfs 140k. > > What the hell are you doing? Compiling with debugging or something? Yep, sorry that was uml with debugging info. > The ramfs inode.o file (the only file that ramfs contains) has 376 > bytes of data and 1612 bytes of code. BYTES. The whole final object > file with all the relocation information is > > -rw-r--r-- 1 torvalds eng 5734 May 16 10:58 ramfs.o > > but out of that 5.5kB, only 2kB are actually linked into the kernel > and are used to _run_. -rw-r--r--1 root root 8656 May 16 20:27 fs/ramfs/ramfs.o -rw-r--r--1 root root11688 May 16 20:24 mm/shmem.o-tmpfs -rw-r--r--1 root root18592 May 16 20:20 mm/shmem.o+tmpfs That's an -ac kernel, so ramfs does accounting and is a little bigger than yours. So the read/write support in tmpfs is about the same size as ramfs. Greetings Christoph - 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: [PATCH] rootfs (part 1)
On Wed, 16 May 2001, Linus Torvalds wrote: > > On Wed, 16 May 2001, Alexander Viro wrote: > > > > Linus, patch is the first chunk of rootfs stuff. I've tried to > > get it as small as possible - all it does is addition of absolute root > > on ramfs and necessary changes to mount_root/change_root/sys_pivot_root > > and follow_dotdot. Real root is mounted atop of the "absolute" one. > > Looks ok, but it also feels like 2.5.x stuff to me. Umm... It might be, but * it makes fixing races in fs/super.c easier and we will need that in 2.4 (or, at least, backported to 2.4 at some point) * it's backwards-compatible. * it allows to kill tons of the ugliness in rd.c in obviously correct way, for values of obviously correct equal to "provably equivalent behaviour to the old code" I think that it's OK for 2.4, but then I'm obviously biased (mostly by the fact that I know how much it allows to clean up without breaking any compatibility, including binary compatibility in the kernel). Up to you, indeed. > Also, there's the question of whether to make ramfs just built-in, or make > _tmpfs_ built in - ramfs is certainly simpler, but tmpfs does the same > things and you need that one for shared mappings etc. > > Comments? Well, since all I actually use in the full variant of patch is sys_mknod(), sys_chdir() and sys_mkdir()... IMO tmpfs is an overkill here. Maybe we really need minimal rootfs in the kernel (no regular files) and let ramfs, tmpfs, whatever-device-fs use it as a library. Al - 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: [PATCH] rootfs (part 1)
On 16 May 2001, Christoph Rohland wrote: > cr:/speicher/src/u4ac9 $ ls -l fs/ramfs/ramfs.o > -rw-r--r--1 cr users 141452 Mai 16 19:27 fs/ramfs/ramfs.o _What_? - 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: [PATCH] rootfs (part 1)
On 16 May 2001, Christoph Rohland wrote: > Why do you use ramfs? Most of it is duplicated in tmpfs and ramfs is a > minimal _example_ fs. There was some agreement that this should stay > so. Because what I need is an absolute minimum. Heck, I don't even use regular files (in the full variant of patch, that is). They might become useful, but I can live with mkdir() and mknod(). Moreover, I want it mounted very early. Right now I'm doing that after initcalls, but there's a very good reason to move the thing as early as possible. So the fewer things it uses - the better. - 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: [PATCH] rootfs (part 1)
Linus Torvalds wrote: > What the hell are you doing? Compiling with debugging or something? I'll bet he's using a rootkit 'ls' that shows file sizes in bits. ;-) regards, David -- David L. Parsley Network Administrator, Roanoke College "If I have seen further it is by standing on ye shoulders of Giants." --Isaac Newton - 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: [PATCH] rootfs (part 1)
Christoph Rohland wrote: > > Hi Linus, > > On Wed, 16 May 2001, Linus Torvalds wrote: > > Looks ok, but it also feels like 2.5.x stuff to me. > > > > Also, there's the question of whether to make ramfs just built-in, > > or make _tmpfs_ built in - ramfs is certainly simpler, but tmpfs > > does the same things and you need that one for shared mappings etc. > > > > Comments? > > cr:/speicher/src/u4ac9 $ ls -l mm/shmem.o* > -rw-r--r--1 cr users 154652 Mai 16 19:27 mm/shmem.o-tmpfs > -rw-r--r--1 cr users 180764 Mai 16 19:24 mm/shmem.o+tmpfs > cr:/speicher/src/u4ac9 $ ls -l fs/ramfs/ramfs.o > -rw-r--r--1 cr users 141452 Mai 16 19:27 fs/ramfs/ramfs.o > > So CONFIG_TMPFS adds 26k and ramfs 140k. On what system? I don't think this is a good measure... > [jgarzik@rum linux_2_4]$ ls -l fs/ramfs/ramfs.o > -rw-r--r--1 jgarzik jgarzik 5830 May 15 09:29 fs/ramfs/ramfs.o > [jgarzik@rum linux_2_4]$ ls -l mm/shmem.o (includes tmpfs) > -rw-r--r--1 jgarzik jgarzik 17496 May 15 09:28 mm/shmem.o -- Jeff Garzik | Game called on account of naked chick Building 1024| MandrakeSoft | - 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: [PATCH] rootfs (part 1)
Hi Linus, On Wed, 16 May 2001, Linus Torvalds wrote: > Looks ok, but it also feels like 2.5.x stuff to me. > > Also, there's the question of whether to make ramfs just built-in, > or make _tmpfs_ built in - ramfs is certainly simpler, but tmpfs > does the same things and you need that one for shared mappings etc. > > Comments? cr:/speicher/src/u4ac9 $ ls -l mm/shmem.o* -rw-r--r--1 cr users 154652 Mai 16 19:27 mm/shmem.o-tmpfs -rw-r--r--1 cr users 180764 Mai 16 19:24 mm/shmem.o+tmpfs cr:/speicher/src/u4ac9 $ ls -l fs/ramfs/ramfs.o -rw-r--r--1 cr users 141452 Mai 16 19:27 fs/ramfs/ramfs.o So CONFIG_TMPFS adds 26k and ramfs 140k. Greetings Christoph - 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: [PATCH] rootfs (part 1)
On 16 May 2001, Christoph Rohland wrote: > > cr:/speicher/src/u4ac9 $ ls -l mm/shmem.o* > -rw-r--r--1 cr users 154652 Mai 16 19:27 mm/shmem.o-tmpfs > -rw-r--r--1 cr users 180764 Mai 16 19:24 mm/shmem.o+tmpfs > cr:/speicher/src/u4ac9 $ ls -l fs/ramfs/ramfs.o > -rw-r--r--1 cr users 141452 Mai 16 19:27 fs/ramfs/ramfs.o > > So CONFIG_TMPFS adds 26k and ramfs 140k. What the hell are you doing? Compiling with debugging or something? The ramfs inode.o file (the only file that ramfs contains) has 376 bytes of data and 1612 bytes of code. BYTES. The whole final object file with all the relocation information is -rw-r--r--1 torvalds eng 5734 May 16 10:58 ramfs.o but out of that 5.5kB, only 2kB are actually linked into the kernel and are used to _run_. How do you get it to 140kB? You're doing something _seriously_ wrong. You're off by a factor of 70. Linus - 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: [PATCH] rootfs (part 1)
On Wed, 16 May 2001, Alexander Viro wrote: > > Linus, patch is the first chunk of rootfs stuff. I've tried to > get it as small as possible - all it does is addition of absolute root > on ramfs and necessary changes to mount_root/change_root/sys_pivot_root > and follow_dotdot. Real root is mounted atop of the "absolute" one. Looks ok, but it also feels like 2.5.x stuff to me. Also, there's the question of whether to make ramfs just built-in, or make _tmpfs_ built in - ramfs is certainly simpler, but tmpfs does the same things and you need that one for shared mappings etc. Comments? Linus - 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: [PATCH] rootfs (part 1)
Hi Al, On Wed, 16 May 2001, Alexander Viro wrote: > One point that might be better done differently - since we > need ramfs for boot I've just made fs/Config.in declare CONFIG_RAMFS > as define_bool CONFIG_RAMFS y. If ramfs grows (e.g. gets resource > limits patches from -ac) we might be better off doing a minimal > variant permanently in kernel (calling it rootfs) and making > ramfs use rootfs methods. It's completely separate issue, so I've > done it the simplest way for the time being. Why do you use ramfs? Most of it is duplicated in tmpfs and ramfs is a minimal _example_ fs. There was some agreement that this should stay so. Look into mm/shmem.c and look how little is added by CONFIG_TMPFS and how much is duplicated from ramfs If we really think the added swap vector per file in tmpfs is a major overhead we should add the nonswapping functions there. Greetings Christoph - 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/
[PATCH] rootfs (part 1)
Linus, patch is the first chunk of rootfs stuff. I've tried to
get it as small as possible - all it does is addition of absolute root
on ramfs and necessary changes to mount_root/change_root/sys_pivot_root
and follow_dotdot. Real root is mounted atop of the "absolute" one.
More interesting stuff lives in the next parts - once we
have rootfs we can get rid of a lot of cruft in fs/super.c around
mounting real root and switching it after initrd. In particular,
we can get rid of the umount_root flag in do_umount() and kill_super()
which allows much cleaner handling of vfsmounts. I'll try to feed this
stuff in small and obvious pieces.
It's transparent to userland - the only visible effect is
an extra line in /proc/mounts. Moreover, it's transparent to the
kernel - the only functions that really care are those that do
the first mount.
One point that might be better done differently - since we
need ramfs for boot I've just made fs/Config.in declare CONFIG_RAMFS
as define_bool CONFIG_RAMFS y. If ramfs grows (e.g. gets resource
limits patches from -ac) we might be better off doing a minimal
variant permanently in kernel (calling it rootfs) and making
ramfs use rootfs methods. It's completely separate issue, so I've
done it the simplest way for the time being.
And yes, patch got testing. Please, apply.
Al
diff -urN S5-pre2-init/fs/Config.in S5-pre2-rootfs/fs/Config.in
--- S5-pre2-init/fs/Config.in Sat Apr 28 02:12:55 2001
+++ S5-pre2-rootfs/fs/Config.in Wed May 16 03:14:12 2001
@@ -32,7 +32,8 @@
fi
tristate 'Compressed ROM file system support' CONFIG_CRAMFS
bool 'Virtual memory file system support (former shm fs)' CONFIG_TMPFS
-tristate 'Simple RAM-based file system support' CONFIG_RAMFS
+define_bool CONFIG_RAMFS y
+# tristate 'Simple RAM-based file system support' CONFIG_RAMFS
tristate 'ISO 9660 CDROM file system support' CONFIG_ISO9660_FS
dep_mbool ' Microsoft Joliet CDROM extensions' CONFIG_JOLIET $CONFIG_ISO9660_FS
diff -urN S5-pre2-init/fs/namei.c S5-pre2-rootfs/fs/namei.c
--- S5-pre2-init/fs/namei.c Sat Apr 28 02:12:56 2001
+++ S5-pre2-rootfs/fs/namei.c Wed May 16 02:06:02 2001
@@ -410,6 +410,8 @@
mntput(nd->mnt);
nd->mnt = parent;
}
+ while (d_mountpoint(nd->dentry) && __follow_down(>mnt, >dentry))
+ ;
}
/*
* Name resolution.
diff -urN S5-pre2-init/fs/super.c S5-pre2-rootfs/fs/super.c
--- S5-pre2-init/fs/super.c Tue May 15 03:51:04 2001
+++ S5-pre2-rootfs/fs/super.c Wed May 16 04:15:26 2001
@@ -1447,17 +1447,52 @@
return retval;
}
-void __init mount_root(void)
+void __init mount_rootfs(void)
+{
+ struct file_system_type * fs_type;
+ struct super_block * sb;
+ struct vfsmount *vfsmnt;
+
+ fs_type = get_fs_type("ramfs");
+
+ if (!fs_type)
+ panic("ramfs not built in");
+
+ sb = get_sb_nodev(fs_type, 0, NULL);
+ put_filesystem(fs_type);
+
+ if (!sb)
+ panic("unable to create rootfs");
+
+ vfsmnt = add_vfsmnt(NULL, sb->s_root, "rootfs");
+ if (!vfsmnt)
+ panic("can't create a single vfsmount");
+
+ up(_sem);
+
+ set_fs_root(current->fs, vfsmnt, sb->s_root);
+ set_fs_pwd(current->fs, vfsmnt, sb->s_root);
+}
+
+void __init mount_root(char *to)
{
struct file_system_type * fs_type;
struct super_block * sb;
struct vfsmount *vfsmnt;
struct block_device *bdev = NULL;
mode_t mode;
- int retval;
+ int retval = 0;
void *handle;
char path[64];
int path_start = -1;
+ struct nameidata root_nd;
+
+ if (path_init(to, LOOKUP_POSITIVE|LOOKUP_DIRECTORY, _nd))
+ retval = path_walk(to, _nd);
+
+ if (retval)
+ panic("Where do I mount root?");
+
#ifdef CONFIG_ROOT_NFS
void *data;
@@ -1591,10 +1626,11 @@
devfs_mk_symlink (NULL, "root", DEVFS_FL_DEFAULT,
path + 5 + path_start, NULL, NULL);
memcpy (path + path_start, "/dev/", 5);
- vfsmnt = add_vfsmnt(NULL, sb->s_root, path + path_start);
+ vfsmnt = add_vfsmnt(_nd, sb->s_root, path + path_start);
}
else
- vfsmnt = add_vfsmnt(NULL, sb->s_root, "/dev/root");
+ vfsmnt = add_vfsmnt(_nd, sb->s_root, "/dev/root");
+ path_release(_nd);
/* FIXME: if something will try to umount us right now... */
if (vfsmnt) {
set_fs_root(current->fs, vfsmnt, sb->s_root);
@@ -1647,10 +1683,8 @@
asmlinkage long sys_pivot_root(const char *new_root, const char *put_old)
{
- struct dentry *root;
- struct vfsmount *root_mnt;
struct vfsmount *tmp;
- struct nameidata new_nd, old_nd;
+ struct nameidata new_nd, old_nd, root_nd, parent_nd;
char *name;
[PATCH] rootfs (part 1)
Linus, patch is the first chunk of rootfs stuff. I've tried to
get it as small as possible - all it does is addition of absolute root
on ramfs and necessary changes to mount_root/change_root/sys_pivot_root
and follow_dotdot. Real root is mounted atop of the absolute one.
More interesting stuff lives in the next parts - once we
have rootfs we can get rid of a lot of cruft in fs/super.c around
mounting real root and switching it after initrd. In particular,
we can get rid of the umount_root flag in do_umount() and kill_super()
which allows much cleaner handling of vfsmounts. I'll try to feed this
stuff in small and obvious pieces.
It's transparent to userland - the only visible effect is
an extra line in /proc/mounts. Moreover, it's transparent to the
kernel - the only functions that really care are those that do
the first mount.
One point that might be better done differently - since we
need ramfs for boot I've just made fs/Config.in declare CONFIG_RAMFS
as define_bool CONFIG_RAMFS y. If ramfs grows (e.g. gets resource
limits patches from -ac) we might be better off doing a minimal
variant permanently in kernel (calling it rootfs) and making
ramfs use rootfs methods. It's completely separate issue, so I've
done it the simplest way for the time being.
And yes, patch got testing. Please, apply.
Al
diff -urN S5-pre2-init/fs/Config.in S5-pre2-rootfs/fs/Config.in
--- S5-pre2-init/fs/Config.in Sat Apr 28 02:12:55 2001
+++ S5-pre2-rootfs/fs/Config.in Wed May 16 03:14:12 2001
@@ -32,7 +32,8 @@
fi
tristate 'Compressed ROM file system support' CONFIG_CRAMFS
bool 'Virtual memory file system support (former shm fs)' CONFIG_TMPFS
-tristate 'Simple RAM-based file system support' CONFIG_RAMFS
+define_bool CONFIG_RAMFS y
+# tristate 'Simple RAM-based file system support' CONFIG_RAMFS
tristate 'ISO 9660 CDROM file system support' CONFIG_ISO9660_FS
dep_mbool ' Microsoft Joliet CDROM extensions' CONFIG_JOLIET $CONFIG_ISO9660_FS
diff -urN S5-pre2-init/fs/namei.c S5-pre2-rootfs/fs/namei.c
--- S5-pre2-init/fs/namei.c Sat Apr 28 02:12:56 2001
+++ S5-pre2-rootfs/fs/namei.c Wed May 16 02:06:02 2001
@@ -410,6 +410,8 @@
mntput(nd-mnt);
nd-mnt = parent;
}
+ while (d_mountpoint(nd-dentry) __follow_down(nd-mnt, nd-dentry))
+ ;
}
/*
* Name resolution.
diff -urN S5-pre2-init/fs/super.c S5-pre2-rootfs/fs/super.c
--- S5-pre2-init/fs/super.c Tue May 15 03:51:04 2001
+++ S5-pre2-rootfs/fs/super.c Wed May 16 04:15:26 2001
@@ -1447,17 +1447,52 @@
return retval;
}
-void __init mount_root(void)
+void __init mount_rootfs(void)
+{
+ struct file_system_type * fs_type;
+ struct super_block * sb;
+ struct vfsmount *vfsmnt;
+
+ fs_type = get_fs_type(ramfs);
+
+ if (!fs_type)
+ panic(ramfs not built in);
+
+ sb = get_sb_nodev(fs_type, 0, NULL);
+ put_filesystem(fs_type);
+
+ if (!sb)
+ panic(unable to create rootfs);
+
+ vfsmnt = add_vfsmnt(NULL, sb-s_root, rootfs);
+ if (!vfsmnt)
+ panic(can't create a single vfsmount);
+
+ up(mount_sem);
+
+ set_fs_root(current-fs, vfsmnt, sb-s_root);
+ set_fs_pwd(current-fs, vfsmnt, sb-s_root);
+}
+
+void __init mount_root(char *to)
{
struct file_system_type * fs_type;
struct super_block * sb;
struct vfsmount *vfsmnt;
struct block_device *bdev = NULL;
mode_t mode;
- int retval;
+ int retval = 0;
void *handle;
char path[64];
int path_start = -1;
+ struct nameidata root_nd;
+
+ if (path_init(to, LOOKUP_POSITIVE|LOOKUP_DIRECTORY, root_nd))
+ retval = path_walk(to, root_nd);
+
+ if (retval)
+ panic(Where do I mount root?);
+
#ifdef CONFIG_ROOT_NFS
void *data;
@@ -1591,10 +1626,11 @@
devfs_mk_symlink (NULL, root, DEVFS_FL_DEFAULT,
path + 5 + path_start, NULL, NULL);
memcpy (path + path_start, /dev/, 5);
- vfsmnt = add_vfsmnt(NULL, sb-s_root, path + path_start);
+ vfsmnt = add_vfsmnt(root_nd, sb-s_root, path + path_start);
}
else
- vfsmnt = add_vfsmnt(NULL, sb-s_root, /dev/root);
+ vfsmnt = add_vfsmnt(root_nd, sb-s_root, /dev/root);
+ path_release(root_nd);
/* FIXME: if something will try to umount us right now... */
if (vfsmnt) {
set_fs_root(current-fs, vfsmnt, sb-s_root);
@@ -1647,10 +1683,8 @@
asmlinkage long sys_pivot_root(const char *new_root, const char *put_old)
{
- struct dentry *root;
- struct vfsmount *root_mnt;
struct vfsmount *tmp;
- struct nameidata new_nd, old_nd;
+ struct nameidata new_nd, old_nd, root_nd, parent_nd;
char *name;
int
Re: [PATCH] rootfs (part 1)
Hi Al, On Wed, 16 May 2001, Alexander Viro wrote: One point that might be better done differently - since we need ramfs for boot I've just made fs/Config.in declare CONFIG_RAMFS as define_bool CONFIG_RAMFS y. If ramfs grows (e.g. gets resource limits patches from -ac) we might be better off doing a minimal variant permanently in kernel (calling it rootfs) and making ramfs use rootfs methods. It's completely separate issue, so I've done it the simplest way for the time being. Why do you use ramfs? Most of it is duplicated in tmpfs and ramfs is a minimal _example_ fs. There was some agreement that this should stay so. Look into mm/shmem.c and look how little is added by CONFIG_TMPFS and how much is duplicated from ramfs If we really think the added swap vector per file in tmpfs is a major overhead we should add the nonswapping functions there. Greetings Christoph - 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: [PATCH] rootfs (part 1)
On Wed, 16 May 2001, Alexander Viro wrote: Linus, patch is the first chunk of rootfs stuff. I've tried to get it as small as possible - all it does is addition of absolute root on ramfs and necessary changes to mount_root/change_root/sys_pivot_root and follow_dotdot. Real root is mounted atop of the absolute one. Looks ok, but it also feels like 2.5.x stuff to me. Also, there's the question of whether to make ramfs just built-in, or make _tmpfs_ built in - ramfs is certainly simpler, but tmpfs does the same things and you need that one for shared mappings etc. Comments? Linus - 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: [PATCH] rootfs (part 1)
Christoph Rohland wrote: Hi Linus, On Wed, 16 May 2001, Linus Torvalds wrote: Looks ok, but it also feels like 2.5.x stuff to me. Also, there's the question of whether to make ramfs just built-in, or make _tmpfs_ built in - ramfs is certainly simpler, but tmpfs does the same things and you need that one for shared mappings etc. Comments? cr:/speicher/src/u4ac9 $ ls -l mm/shmem.o* -rw-r--r--1 cr users 154652 Mai 16 19:27 mm/shmem.o-tmpfs -rw-r--r--1 cr users 180764 Mai 16 19:24 mm/shmem.o+tmpfs cr:/speicher/src/u4ac9 $ ls -l fs/ramfs/ramfs.o -rw-r--r--1 cr users 141452 Mai 16 19:27 fs/ramfs/ramfs.o So CONFIG_TMPFS adds 26k and ramfs 140k. On what system? I don't think this is a good measure... [jgarzik@rum linux_2_4]$ ls -l fs/ramfs/ramfs.o -rw-r--r--1 jgarzik jgarzik 5830 May 15 09:29 fs/ramfs/ramfs.o [jgarzik@rum linux_2_4]$ ls -l mm/shmem.o (includes tmpfs) -rw-r--r--1 jgarzik jgarzik 17496 May 15 09:28 mm/shmem.o -- Jeff Garzik | Game called on account of naked chick Building 1024| MandrakeSoft | - 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: [PATCH] rootfs (part 1)
Hi Linus, On Wed, 16 May 2001, Linus Torvalds wrote: Looks ok, but it also feels like 2.5.x stuff to me. Also, there's the question of whether to make ramfs just built-in, or make _tmpfs_ built in - ramfs is certainly simpler, but tmpfs does the same things and you need that one for shared mappings etc. Comments? cr:/speicher/src/u4ac9 $ ls -l mm/shmem.o* -rw-r--r--1 cr users 154652 Mai 16 19:27 mm/shmem.o-tmpfs -rw-r--r--1 cr users 180764 Mai 16 19:24 mm/shmem.o+tmpfs cr:/speicher/src/u4ac9 $ ls -l fs/ramfs/ramfs.o -rw-r--r--1 cr users 141452 Mai 16 19:27 fs/ramfs/ramfs.o So CONFIG_TMPFS adds 26k and ramfs 140k. Greetings Christoph - 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: [PATCH] rootfs (part 1)
On 16 May 2001, Christoph Rohland wrote: cr:/speicher/src/u4ac9 $ ls -l mm/shmem.o* -rw-r--r--1 cr users 154652 Mai 16 19:27 mm/shmem.o-tmpfs -rw-r--r--1 cr users 180764 Mai 16 19:24 mm/shmem.o+tmpfs cr:/speicher/src/u4ac9 $ ls -l fs/ramfs/ramfs.o -rw-r--r--1 cr users 141452 Mai 16 19:27 fs/ramfs/ramfs.o So CONFIG_TMPFS adds 26k and ramfs 140k. What the hell are you doing? Compiling with debugging or something? The ramfs inode.o file (the only file that ramfs contains) has 376 bytes of data and 1612 bytes of code. BYTES. The whole final object file with all the relocation information is -rw-r--r--1 torvalds eng 5734 May 16 10:58 ramfs.o but out of that 5.5kB, only 2kB are actually linked into the kernel and are used to _run_. How do you get it to 140kB? You're doing something _seriously_ wrong. You're off by a factor of 70. Linus - 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: [PATCH] rootfs (part 1)
Linus Torvalds wrote: What the hell are you doing? Compiling with debugging or something? I'll bet he's using a rootkit 'ls' that shows file sizes in bits. ;-) regards, David -- David L. Parsley Network Administrator, Roanoke College If I have seen further it is by standing on ye shoulders of Giants. --Isaac Newton - 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: [PATCH] rootfs (part 1)
On 16 May 2001, Christoph Rohland wrote: Why do you use ramfs? Most of it is duplicated in tmpfs and ramfs is a minimal _example_ fs. There was some agreement that this should stay so. Because what I need is an absolute minimum. Heck, I don't even use regular files (in the full variant of patch, that is). They might become useful, but I can live with mkdir() and mknod(). Moreover, I want it mounted very early. Right now I'm doing that after initcalls, but there's a very good reason to move the thing as early as possible. So the fewer things it uses - the better. - 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: [PATCH] rootfs (part 1)
On 16 May 2001, Christoph Rohland wrote: cr:/speicher/src/u4ac9 $ ls -l fs/ramfs/ramfs.o -rw-r--r--1 cr users 141452 Mai 16 19:27 fs/ramfs/ramfs.o _What_? - 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: [PATCH] rootfs (part 1)
On Wed, 16 May 2001, Linus Torvalds wrote: On Wed, 16 May 2001, Alexander Viro wrote: Linus, patch is the first chunk of rootfs stuff. I've tried to get it as small as possible - all it does is addition of absolute root on ramfs and necessary changes to mount_root/change_root/sys_pivot_root and follow_dotdot. Real root is mounted atop of the absolute one. Looks ok, but it also feels like 2.5.x stuff to me. Umm... It might be, but * it makes fixing races in fs/super.c easier and we will need that in 2.4 (or, at least, backported to 2.4 at some point) * it's backwards-compatible. * it allows to kill tons of the ugliness in rd.c in obviously correct way, for values of obviously correct equal to provably equivalent behaviour to the old code I think that it's OK for 2.4, but then I'm obviously biased (mostly by the fact that I know how much it allows to clean up without breaking any compatibility, including binary compatibility in the kernel). Up to you, indeed. Also, there's the question of whether to make ramfs just built-in, or make _tmpfs_ built in - ramfs is certainly simpler, but tmpfs does the same things and you need that one for shared mappings etc. Comments? Well, since all I actually use in the full variant of patch is sys_mknod(), sys_chdir() and sys_mkdir()... IMO tmpfs is an overkill here. Maybe we really need minimal rootfs in the kernel (no regular files) and let ramfs, tmpfs, whatever-device-fs use it as a library. Al - 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: [PATCH] rootfs (part 1)
Hi Linus, On Wed, 16 May 2001, Linus Torvalds wrote: On 16 May 2001, Christoph Rohland wrote: cr:/speicher/src/u4ac9 $ ls -l mm/shmem.o* -rw-r--r--1 cr users 154652 Mai 16 19:27 mm/shmem.o-tmpfs -rw-r--r--1 cr users 180764 Mai 16 19:24 mm/shmem.o+tmpfs cr:/speicher/src/u4ac9 $ ls -l fs/ramfs/ramfs.o -rw-r--r--1 cr users 141452 Mai 16 19:27 fs/ramfs/ramfs.o So CONFIG_TMPFS adds 26k and ramfs 140k. What the hell are you doing? Compiling with debugging or something? Yep, sorry that was uml with debugging info. The ramfs inode.o file (the only file that ramfs contains) has 376 bytes of data and 1612 bytes of code. BYTES. The whole final object file with all the relocation information is -rw-r--r-- 1 torvalds eng 5734 May 16 10:58 ramfs.o but out of that 5.5kB, only 2kB are actually linked into the kernel and are used to _run_. -rw-r--r--1 root root 8656 May 16 20:27 fs/ramfs/ramfs.o -rw-r--r--1 root root11688 May 16 20:24 mm/shmem.o-tmpfs -rw-r--r--1 root root18592 May 16 20:20 mm/shmem.o+tmpfs That's an -ac kernel, so ramfs does accounting and is a little bigger than yours. So the read/write support in tmpfs is about the same size as ramfs. Greetings Christoph - 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: [PATCH] rootfs (part 1)
Hi Alexander, On Wed, 16 May 2001, Alexander Viro wrote: Because what I need is an absolute minimum. Heck, I don't even use regular files (in the full variant of patch, that is). They might become useful, but I can live with mkdir() and mknod(). So what about adding shmem_mknod and shmem_mkdir to the core shmem.c part? They are now under CONFIG_TMPFS but are only ~20 lines of code. Greetings Christoph - 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: [PATCH] rootfs (part 1)
Followup to: [EMAIL PROTECTED] By author:Alexander Viro [EMAIL PROTECTED] In newsgroup: linux.dev.kernel Well, since all I actually use in the full variant of patch is sys_mknod(), sys_chdir() and sys_mkdir()... IMO tmpfs is an overkill here. Maybe we really need minimal rootfs in the kernel (no regular files) and let ramfs, tmpfs, whatever-device-fs use it as a library. One thing that I thought was really spiffy was someone who had done patches to populate a ramfs from a tarball loaded via the initrd bootloader protocol... call it initial ramfs. It allowed a whole lot of cleanup -- the initrd isn't magic anymore (instead use pivot_root), and it gets rid of the rd stuff. At the same time it does allow the full flexibility of a fullblown filesystem that can be populated with arbitrary contents. -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! Unix gives you enough rope to shoot yourself in the foot. http://www.zytor.com/~hpa/puzzle.txt - 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: [PATCH] rootfs (part 1)
On 16 May 2001, H. Peter Anvin wrote: Followup to: [EMAIL PROTECTED] By author:Alexander Viro [EMAIL PROTECTED] In newsgroup: linux.dev.kernel Well, since all I actually use in the full variant of patch is sys_mknod(), sys_chdir() and sys_mkdir()... IMO tmpfs is an overkill here. Maybe we really need minimal rootfs in the kernel (no regular files) and let ramfs, tmpfs, whatever-device-fs use it as a library. One thing that I thought was really spiffy was someone who had done patches to populate a ramfs from a tarball loaded via the initrd bootloader protocol... call it initial ramfs. It allowed a whole lot of cleanup -- the initrd isn't magic anymore (instead use pivot_root), and it gets rid of the rd stuff. At the same time it does allow the full flexibility of a fullblown filesystem that can be populated with arbitrary contents. In full variant of patch I don't _have_ mount_root(9). It's done by mount(2). Period. Initrd or not. Notice that rootfs stays absolute root forever - it's much more convenient for fs/super.c, since you can get rid of many kludges that way. So I'm not too happy about populating rootfs with tons of files. BTW, loading initrd is done by open(2), read(2) and write(2) - none of this fake struct file business anymore. So late-boot stuff (mounting root, unpacking initrd, mounting devfs if asked to, loading initrd from floppies, moving initrd around - the whole whorehouse) is actually done by sane, normal system calls. And it's very easy to expand - I refused to apply any fancy patches simply because I wanted 100% compatibility with all existing boot setups, no matter how silly they are. If behaviour is absent in Linus' tree - sorry. However, playing with that stuff becomes much easier - essentially it's a userland code. You have an empty, writable fs, your root and cwd are on it, you can do any system calls you want. So if you want this untar-into-ramfs - well, more power to you. I'd recommend to use a separate instance of ramfs for that, though, so that you could easily get rid of it afterwards. Again, at that point you have normal userland environment, so doing whatever you want to do doesn't require any kernel-specific stuff. Write as if you were adding your code to the beginning of /sbin/init. - 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: [PATCH] rootfs (part 1)
Alexander Viro wrote: In full variant of patch I don't _have_ mount_root(9). It's done by mount(2). Period. Initrd or not. Notice that rootfs stays absolute root forever - it's much more convenient for fs/super.c, since you can get rid of many kludges that way. So I'm not too happy about populating rootfs with tons of files. BTW, loading initrd is done by open(2), read(2) and write(2) - none of this fake struct file business anymore. OK, I see what you're doing now. However, I'm confused what you mean with rootfs stays absolute root forever -- does that mean that you mount the new root on top of /, and so the rootfs remains in the system never to be reclaimed, as opposed to pivot_root-ing it? -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! Unix gives you enough rope to shoot yourself in the foot. http://www.zytor.com/~hpa/puzzle.txt - 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: [PATCH] rootfs (part 1)
On Wed, 16 May 2001, H. Peter Anvin wrote: Alexander Viro wrote: In full variant of patch I don't _have_ mount_root(9). It's done by mount(2). Period. Initrd or not. Notice that rootfs stays absolute root forever - it's much more convenient for fs/super.c, since you can get rid of many kludges that way. So I'm not too happy about populating rootfs with tons of files. BTW, loading initrd is done by open(2), read(2) and write(2) - none of this fake struct file business anymore. OK, I see what you're doing now. However, I'm confused what you mean with rootfs stays absolute root forever -- does that mean that you mount the new root on top of /, and so the rootfs remains in the system never to be reclaimed, as opposed to pivot_root-ing it? Yes. Pivot_root works, all right, but it rotates (your process' root, old, new). So it works in chroot correctly now. And since we chroot out of the absolute root when we mount initrd (or final root, for that matter) any setup that used pivot_root keeps working as it did. As for never to be reclaimed... Let's see: 1 struct super_block 1 struct vfsmount couple of struct dentry couple of struct inode (for values of couple from 1 to 4; we can reduce it to 1 but I didn't bother with that; all it takes is a couple of calls of sys_rmdir()/sys_unlink()). Compared to the amount of space we free in .code of fs/super.c it's noise. - 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: [PATCH] rootfs (part 1)
Linus, patch is the first chunk of rootfs stuff. I've tried to get it as small as possible - all it does is addition of absolute root on ramfs and necessary changes to mount_root/change_root/sys_pivot_root and follow_dotdot. Real root is mounted atop of the absolute one. Surely this is getting right into 2.5 stuff. - 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: [PATCH] rootfs (part 1)
cr:/speicher/src/u4ac9 $ ls -l mm/shmem.o* -rw-r--r--1 cr users 154652 Mai 16 19:27 mm/shmem.o-tmpfs -rw-r--r--1 cr users 180764 Mai 16 19:24 mm/shmem.o+tmpfs cr:/speicher/src/u4ac9 $ ls -l fs/ramfs/ramfs.o -rw-r--r--1 cr users 141452 Mai 16 19:27 fs/ramfs/ramfs.o So CONFIG_TMPFS adds 26k and ramfs 140k. I think you have a major tool problem. bash-2.04$ size mm/shmem.o textdata bss dec hex filename 7422 572 079941f3a mm/shmem.o bash-2.04$ size fs/ramfs/ramfs.o textdata bss dec hex filename 3185 368 03553 de1 fs/ramfs/ramfs.o Never trust ls -l size for binaries, its very very unrelated. So ramfs is 3553 bytes, shmem.o in total is 8K on current -ac. - 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: [PATCH] rootfs (part 1)
On Thu, 17 May 2001, Alan Cox wrote: Linus, patch is the first chunk of rootfs stuff. I've tried to get it as small as possible - all it does is addition of absolute root on ramfs and necessary changes to mount_root/change_root/sys_pivot_root and follow_dotdot. Real root is mounted atop of the absolute one. Surely this is getting right into 2.5 stuff. Maybe. I still think that it's local enough to be tolerable in 2.4, but postponing it until 2.5 is not a big deal. I'll put that (and the rest of rootfs stuff) on anonftp and post CFT. I'd appreciate review of that code once the splitup is done, if you have time for 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/
