All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Pavel Machek <pavel@ucw.cz>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	Pawel Plociennik <paplociennik@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2.6.24] chroot= as a new kernel parameter
Date: Thu, 6 Mar 2008 22:42:18 +0100	[thread overview]
Message-ID: <20080306214218.GA886@elte.hu> (raw)
In-Reply-To: <20080306212028.GB1747@elf.ucw.cz>


* Pavel Machek <pavel@ucw.cz> wrote:

> No, that will not work, if you don't have libraries at /. This should
> be exact replacement:
> 
> init=/working_distro/lib/ld-linux.so.2 --library-path 
> /working_distro/lib /working_distro/usr/sbin/chroot /working_distro/ 
> /sbin/init

ouch ...

> ...assuming your chroot uses ld-linux.so.2. I believe above is ugly 
> enough to warrant merge of chroot= option.
> 
> ...heck, how many tries would it take to get that right? Is chroot 
> /usr/sbin or /sbin?
> 
> This really should be in kernel, I should not have to partition my
> disk to get booting to few different distros.

agreed ...

i really find it so disheartening at times that people fight trivial 
usability additions tooth and nail in a _9 million lines of code_ kernel 
with a ... "bloat" argument.

Lets face it: Linux is _still_ hard and a pain to administer, our kernel 
boot parameters are ad-hoc, they dont match up to the .config parameters 
and it is all a total mess. There's absolutely no design behind them 
(look at all the inconsistent parameter forms for turning off smp, acpi, 
hpet, nohz, etc.).

if RAM overhead of a new boot option would really be an issue on smaller 
setups then the right solution is to make a new .config option that 
hardcodes a specific command line and _disable_ all the commandline 
parsing. That would also be a nice security feature for certain setups 
and would save _a lot more_ RAM than another rejected boot parameter. 
Really, all the 'bloat' based objections are totally, utterly silly.

i had a similar experience when i added the relatime boot option:

  http://people.redhat.com/mingo/relatime-patches/improve-relatime.patch

Look back the lkml discussion for all the "bloat" and "use /etc/fstab" 
clowning around that happened when i sent that patch ... and we still 
have no good configuration vectors to turn atime off. I'd rate it good 
comedy that happened around that patch: "Kernel hackers shoot in their 
own foot and are proud of it".

multiple, consistent vectors for configurability are _GOOD_. That was 
the success story behind Apache. Forcing everyone into a "you must use 
an initrd for this" idea is 80's thinking and actively harmful to Linux.

	Ingo

  parent reply	other threads:[~2008-03-06 21:42 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-06  5:01 [PATCH 2.6.24] chroot= as a new kernel parameter Pawel Plociennik
2008-03-06  4:58 ` H. Peter Anvin
2008-03-06 10:27   ` Ingo Molnar
2008-03-06 15:17     ` H. Peter Anvin
2008-03-06 20:57       ` Ingo Molnar
2008-03-06 21:05         ` H. Peter Anvin
2008-03-06 21:20       ` Pavel Machek
2008-03-06 21:30         ` H. Peter Anvin
2008-03-06 22:05           ` Matthias Schniedermeyer
2008-03-07 10:36           ` Bernd Petrovitsch
2008-03-07 12:28             ` H. Peter Anvin
2008-03-06 21:42         ` Ingo Molnar [this message]
2008-03-06 21:50           ` H. Peter Anvin
2008-03-06 22:22             ` Ingo Molnar
2008-03-07  4:53         ` Greg Schafer
2008-03-07  9:27         ` Måns Rullgård
2008-03-06 16:54     ` Pawel Plociennik
2008-03-06 15:47   ` Pawel Plociennik
2008-03-06 10:34 ` Chris Wedgwood
2008-03-06 10:44   ` Ingo Molnar
2008-03-06 11:22     ` Chris Wedgwood
2008-03-06 11:37       ` Ingo Molnar
2008-03-06 11:53         ` Pavel Machek
2008-03-06 19:46           ` Peter Zijlstra
2008-03-06 20:57             ` Willy Tarreau
2008-03-07  8:23         ` Chris Wedgwood
  -- strict thread matches above, loose matches on Subject: below --
2008-03-07 21:04 devzero
2008-03-07 22:32 ` Christian Kujau
2008-03-08 14:10 Al Boldi
2008-03-08 14:28 ` Christian Kujau
2008-03-08 16:34   ` Al Boldi

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=20080306214218.GA886@elte.hu \
    --to=mingo@elte.hu \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paplociennik@gmail.com \
    --cc=pavel@ucw.cz \
    /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.