linux-kernel - Re: [PATCH]: typo in init/initramfs.c

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 8 Dec 2006 16:58:24 +0300
From:	Al Boldi <a1426z@...ab.com>
To:	Jean-Paul Saman <jean-paul.saman@....com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH]: typo in init/initramfs.c

Jean-Paul Saman wrote:
> linux-kernel-owner@...r.kernel.org wrote on 06-12-2006 19:17:27:
> > Jean-Paul Saman wrote:
> > > In populate_rootfs() the printk on line 554. It says "Unpacking
> > > initramfs..", which is confusing because if that line is reached the
> > > code has already decided that the image is an initrd image.
> >
> > Are you sure?
>
> Yes.

Are you really sure?

> > > The printk is thus
> > > wrong in stating that it is unpacking an "initramfs". It should says
> > > "initrd" instead. The attached patch corrects this typo.
> > >
> > > Signed-off-by: Jean-Paul Saman <jean-paul.saman@....com>
> > >
> > > diff --git a/init/initramfs.c b/init/initramfs.c
> > > index d28c109..f6020db 100644
> > > --- a/init/initramfs.c
> > > +++ b/init/initramfs.c
> > > @@ -551,7 +551,7 @@ #ifdef CONFIG_BLK_DEV_RAM
> >
> > This is where initramfs is discerned from initrd, as both are available.
> >
> > >                         free_initrd();
> > >                 }
> > >  #else
> >
> > Otherwise it's initramfs only.
>
> No otherwise it falls under CONFIG_BLK_DEV_INITRD and it that suggests it
> must be a initrd, not a initramfs as the original printk() suggests.

This is what 2.6.19 says:

=========================
#ifdef CONFIG_BLK_DEV_INITRD
	if (initrd_start) {
#ifdef CONFIG_BLK_DEV_RAM
		int fd;
		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");
			unpack_to_rootfs((char *)initrd_start,
				initrd_end - initrd_start, 0);
			free_initrd();
			return;
		}
		printk("it isn't (%s); looks like an initrd\n", err);
		fd = sys_open("/initrd.image", O_WRONLY|O_CREAT, 0700);
		if (fd >= 0) {
			sys_write(fd, (char *)initrd_start,
					initrd_end - initrd_start);
			sys_close(fd);
			free_initrd();
		}
#else // <=== of #ifdef CONFIG_BLK_DEV_RAM
		printk(KERN_INFO "Unpacking initramfs...");
		err = unpack_to_rootfs((char *)initrd_start,
			initrd_end - initrd_start, 0);
		if (err)
			panic(err);
		printk(" done\n");
		free_initrd();
#endif // <=== of #ifdef CONFIG_BLK_DEV_RAM
	}
#endif // <=== of #ifdef CONFIG_BLK_DEV_INITRD
=========================

Maybe you're getting confused with the dual intitrd naming-convention.  
InitRD used to mean InitRamDisk only, now it means InitRamFS and InitRamDisk 
#ifdef CONFIG_BLK_DEV_RAM, else it means InitRamFS only.

But still, it's rather refreshing to see you so convinced.


Thanks!

--
Al

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/