All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Schroeder <mls@suse.de>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.6 early userspace init
Date: Fri, 14 Nov 2003 17:39:52 +0100	[thread overview]
Message-ID: <20031114163952.GA17972@suse.de> (raw)
In-Reply-To: <bp0t9i$ta3$1@cesium.transmeta.com>

On Thu, Nov 13, 2003 at 01:32:34PM -0800, H. Peter Anvin wrote:
> I think it's useful to maintain bass-ackwards compatibility with
> root=, especially since if any hack is put it now, it creates new
> legacy.
> 
> Looking for init, or linuxrc, inside the initramfs makes sense.  It
> should *NOT* be tied to the init= option, though... consider when all
> of this is pulled out of kernel space; you don't want "init=" to break
> finding your RAID volumes when you're trying to find a different
> "real" init binary.

Exactly. People may want to change the root partition with a
root= option, so reserving root=0:0 to flag kinit booting is
IMHO a bad idea. And init=/bin/bash should provide the user
with a mounted root.

So, how's the following patch:

--- init/do_mounts.c.orig	2003-11-12 12:49:12.000000000 +0100
+++ init/do_mounts.c	2003-11-14 17:33:49.000000000 +0100
@@ -14,6 +14,7 @@
 #include "do_mounts.h"
 
 extern int get_filesystem_list(char * buf);
+extern asmlinkage long sys_access(const char * filename, int mode);
 
 int __initdata rd_doload;	/* 1 = load RAM disk, 0 = don't load */
 
@@ -370,6 +371,17 @@
 	mount_block_root("/dev/root", root_mountflags);
 }
 
+static char *kinit_command;
+
+static int __init kinit_setup(char *str)
+{
+	kinit_command = str;
+	return 1;
+}
+
+__setup("kinit=", kinit_setup);
+
+
 /*
  * Prepare the namespace - decide what/where to mount, load ramdisks, etc.
  */
@@ -393,6 +405,16 @@
 	if (initrd_load())
 		goto out;
 
+	/*
+	 * check if there is an early userspace init, if yes
+	 * let it do all the work
+	 */
+	if (kinit_command || sys_access("/sbin/init", 0) == 0) {
+		extern char *execute_command;
+		execute_command = kinit_command ? kinit_command : 0;
+		goto out;
+	}
+
 	if (is_floppy && rd_doload && rd_load_disk(0))
 		ROOT_DEV = Root_RAM0;
 

It also adds a 'kinit' option for the brave users who really
want to specify a diffenent kinit, e.g. 'ash'.

Of course, the kinit program should also be changed to check
for a init=xxx parameter instead of kinit=xxx.

Cheers,
  Michael.

-- 
Michael Schroeder                                   mls@suse.de
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}

      reply	other threads:[~2003-11-14 16:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-12 11:50 2.6 early userspace init Michael Schroeder
2003-11-12 16:45 ` Bryan O'Sullivan
2003-11-12 16:53   ` Michael Schroeder
2003-11-13 21:32   ` H. Peter Anvin
2003-11-14 16:39     ` Michael Schroeder [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20031114163952.GA17972@suse.de \
    --to=mls@suse.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.