linux-kernel - Re: [2.6.24-rc5-mm1] Why CONFIG_BLK_DEV_RAM=m makes \\\"#ifdef CONFIG_BLK_DEV

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] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0712151242340.22877@fbirervta.pbzchgretzou.qr>
Date:	Sat, 15 Dec 2007 12:44:31 +0100 (CET)
From:	Jan Engelhardt <jengelh@...putergmbh.de>
To:	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
cc:	Randy Dunlap <randy.dunlap@...cle.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [2.6.24-rc5-mm1] Why CONFIG_BLK_DEV_RAM=m makes \\\"#ifdef
 CONFIG_BLK_DEV_RAM\\\" false?


On Dec 14 2007 15:15, Tetsuo Handa wrote:
>Hello.
>
>Randy Dunlap <randy.dunlap@...cle.com> wrote:
>> I don't think that this is a change from the recent past.
>
>Oh, it is my mistake.
>
>I found that choosing CONFIG_BLK_DEV_RAM=m makes
>impossible to pass an initrd image since
>populate_rootfs() in init/initramfs.c omits
>code for checking whether the image is an initrd or not.

I believe it is (also?) due to /dev/ram0 not being available
where the initrd usually gets copied into.

initramfs continues to work, and that is what should I think
should be used for any new projects.

>But I didn't know CONFIG_BLK_DEV_RAM is tristate.
>So, I have to change to CONFIG_BLK_DEV_RAM=y when
>I want to pass an initrd image after "make allmodconfig".
--
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/