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

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".

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

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

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

On Mon Aug 8 07:57:37 PDT 2005, Grzegorz Kulewski wrote:
> 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?
The only dependancy on BLOCK_DEV_INITRD by initramfs is that you will
end up with a /initrd.data file locked in ramfs if you miss the
format.   do_mounts_initrd is needed only for the initrd* globals
at the top, those could be moved.

In short, its easy to remove the depenancy today, there is no magic
sharing of the major number as in the past.

milton

On Wed, Aug 10, Milton Miller wrote:
> The only dependancy on BLOCK_DEV_INITRD by initramfs is that you will
> end up with a /initrd.data file locked in ramfs if you miss the
> format.   do_mounts_initrd is needed only for the initrd* globals
> at the top, those could be moved.
> 
> In short, its easy to remove the depenancy today, there is no magic
> sharing of the major number as in the past.
Yes, you are right. Only the arch code needs to be updated, removing the
#ifdef CONFIG_BLOCK_DEV_INITRD and make initrd passing unconditional.