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
next prev 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.