[PATCH - RFC] Move initramfs configuration to "General setup"

[PATCH - RFC] Move initramfs configuration to "General setup"

[Sam Ravnborg]

At present the configuration items for initramfs is located in:
Device drivers | Block Drivers | xxx

This is maybe not the most natural place to have it.
So with the following patch it is moved below "General setup",
and relevant config items are collected in a file with a new
home in usr/.

The original reason why I looked into this is the upcoming merge of klibc
and I missed a good place to include the KLIBC relevant config options.
With the Kconfig file added to usr/ is will be a simple menuconfig
in here for all the KLIBC relevant config options.

Any comments?

	Sam

diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -408,48 +408,6 @@ config BLK_DEV_INITRD
 	  "real" root file system, etc. See <file:Documentation/initrd.txt>
 	  for details.
 
-config INITRAMFS_SOURCE
-	string "Initramfs source file(s)"
-	default ""
-	help
-	  This can be either a single cpio archive with a .cpio suffix or a
-	  space-separated list of directories and files for building the
-	  initramfs image.  A cpio archive should contain a filesystem archive
-	  to be used as an initramfs image.  Directories should contain a
-	  filesystem layout to be included in the initramfs image.  Files
-	  should contain entries according to the format described by the
-	  "usr/gen_init_cpio" program in the kernel tree.
-
-	  When multiple directories and files are specified then the
-	  initramfs image will be the aggregate of all of them.
-
-	  See <file:Documentation/early-userspace/README for more details.
-
-	  If you are not sure, leave it blank.
-
-config INITRAMFS_ROOT_UID
-	int "User ID to map to 0 (user root)"
-	depends on INITRAMFS_SOURCE!=""
-	default "0"
-	help
-	  This setting is only meaningful if the INITRAMFS_SOURCE is
-	  contains a directory.  Setting this user ID (UID) to something
-	  other than "0" will cause all files owned by that UID to be
-	  owned by user root in the initial ramdisk image.
-
-	  If you are not sure, leave it set to "0".
-
-config INITRAMFS_ROOT_GID
-	int "Group ID to map to 0 (group root)"
-	depends on INITRAMFS_SOURCE!=""
-	default "0"
-	help
-	  This setting is only meaningful if the INITRAMFS_SOURCE is
-	  contains a directory.  Setting this group ID (GID) to something
-	  other than "0" will cause all files owned by that GID to be
-	  owned by group root in the initial ramdisk image.
-
-	  If you are not sure, leave it set to "0".
 
 #XXX - it makes sense to enable this only for 32-bit subarch's, not for x86_64
 #for instance.
diff --git a/init/Kconfig b/init/Kconfig
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -238,6 +238,8 @@ config CPUSETS
 
 	  Say N if unsure.
 
+source "usr/Kconfig"
+
 menuconfig EMBEDDED
 	bool "Configure standard kernel features (for small systems)"
 	help
diff --git a/usr/Kconfig b/usr/Kconfig
new file mode 100644
--- /dev/null
+++ b/usr/Kconfig
@@ -0,0 +1,46 @@
+#
+# Configuration for initramfs
+#
+
+config INITRAMFS_SOURCE
+	string "Initramfs source file(s)"
+	default ""
+	help
+	  This can be either a single cpio archive with a .cpio suffix or a
+	  space-separated list of directories and files for building the
+	  initramfs image.  A cpio archive should contain a filesystem archive
+	  to be used as an initramfs image.  Directories should contain a
+	  filesystem layout to be included in the initramfs image.  Files
+	  should contain entries according to the format described by the
+	  "usr/gen_init_cpio" program in the kernel tree.
+
+	  When multiple directories and files are specified then the
+	  initramfs image will be the aggregate of all of them.
+
+	  See <file:Documentation/early-userspace/README for more details.
+
+	  If you are not sure, leave it blank.
+
+config INITRAMFS_ROOT_UID
+	int "User ID to map to 0 (user root)"
+	depends on INITRAMFS_SOURCE!=""
+	default "0"
+	help
+	  This setting is only meaningful if the INITRAMFS_SOURCE is
+	  contains a directory.  Setting this user ID (UID) to something
+	  other than "0" will cause all files owned by that UID to be
+	  owned by user root in the initial ramdisk image.
+
+	  If you are not sure, leave it set to "0".
+
+config INITRAMFS_ROOT_GID
+	int "Group ID to map to 0 (group root)"
+	depends on INITRAMFS_SOURCE!=""
+	default "0"
+	help
+	  This setting is only meaningful if the INITRAMFS_SOURCE is
+	  contains a directory.  Setting this group ID (GID) to something
+	  other than "0" will cause all files owned by that GID to be
+	  owned by group root in the initial ramdisk image.
+
+	  If you are not sure, leave it set to "0".

Re: [PATCH - RFC] Move initramfs configuration to "General setup"

[Grzegorz Kulewski]

On Mon, 8 Aug 2005, Sam Ravnborg wrote:

> At present the configuration items for initramfs is located in:
> Device drivers | Block Drivers | xxx
>
> This is maybe not the most natural place to have it.
> So with the following patch it is moved below "General setup",
> and relevant config items are collected in a file with a new
> home in usr/.
>
> The original reason why I looked into this is the upcoming merge of klibc
> and I missed a good place to include the KLIBC relevant config options.
> With the Kconfig file added to usr/ is will be a simple menuconfig
> in here for all the KLIBC relevant config options.
>
> Any comments?

>From my recent experiments it looks like in order to be able to use 
initramfs not compiled into the kernel image but loaded from separate file 
by GRUB or LILO one must also build initrd into the kernel.

Am I right? If so, could somebody split initramfs and initrd (not only at 
configuration level but also at code level)? Shouldn't they be separated 
(and possibly initrd removed after some time)? In the mean time it should 
be documented in *config help.

Also somebody should add more documentation about initramfs (generating, 
writing scripts, producing image, the right method for chroot / pivot_root 
/ ...). It took me whole week to find it out myself and I still have some 
doubths...


Thanks,

Grzegorz Kulewski

Re: [klibc] Re: [PATCH - RFC] Move initramfs configuration to "General setup"

[Olaf Hering]

 On Mon, Aug 08, Grzegorz Kulewski wrote:

> >From my recent experiments it looks like in order to be able to use 
> initramfs not compiled into the kernel image but loaded from separate file 
> by GRUB or LILO one must also build initrd into the kernel.

The file passed from the bootloader to the kernel, which is later
eventually recognized as an initrd, can be everything. But the kernel
code to deal with the memory range containing the file is behind
CONFIG_BLK_DEV_INITRD. The new config options should depend on
BLK_DEV_INITRD

Re: [klibc] Re: [PATCH - RFC] Move initramfs configuration to "General setup"

[Grzegorz Kulewski]

On Mon, 8 Aug 2005, Olaf Hering wrote:

> On Mon, Aug 08, Grzegorz Kulewski wrote:
>
>>> From my recent experiments it looks like in order to be able to use
>> initramfs not compiled into the kernel image but loaded from separate file
>> by GRUB or LILO one must also build initrd into the kernel.
>
> The file passed from the bootloader to the kernel, which is later
> eventually recognized as an initrd, can be everything. But the kernel
> code to deal with the memory range containing the file is behind
> CONFIG_BLK_DEV_INITRD. The new config options should depend on
> BLK_DEV_INITRD

[ Depend or select? ]

So this code should be separated from initrd and put in some other place 
and depend on initrd || initramfs.

>From what I saw reading the code initrd is much more than this code so why 
keep it together?


Thanks,

Grzegorz Kulewski

Re: [klibc] Re: [PATCH - RFC] Move initramfs configuration to "General setup"

[H. Peter Anvin]

Grzegorz Kulewski wrote:
> 
>> From my recent experiments it looks like in order to be able to use 
> 
> initramfs not compiled into the kernel image but loaded from separate 
> file by GRUB or LILO one must also build initrd into the kernel.
> 
> Am I right? If so, could somebody split initramfs and initrd (not only 
> at configuration level but also at code level)? Shouldn't they be 
> separated (and possibly initrd removed after some time)? In the mean 
> time it should be documented in *config help.
> 

Actually, most of CONFIG_INITRD is about being able to pick up the 
second load datum, so it makes sense on the code level at least.

> Also somebody should add more documentation about initramfs (generating, 
> writing scripts, producing image, the right method for chroot / 
> pivot_root / ...). It took me whole week to find it out myself and I 
> still have some doubths...

Yes, that would be good.

	-hpa