From: Matt Porter <porter@cox.net>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Matt Porter <porter@cox.net>, Jeff Garzik <jgarzik@pobox.com>,
Linus Torvalds <torvalds@transmeta.com>,
LKML <linux-kernel@vger.kernel.org>,
viro@math.psu.edu
Subject: Re: [BK PATCHES] initramfs merge, part 1 of N
Date: Sat, 2 Nov 2002 16:36:20 -0700 [thread overview]
Message-ID: <20021102163620.A10451@home.com> (raw)
In-Reply-To: <3DC3C1AA.7060602@zytor.com>; from hpa@zytor.com on Sat, Nov 02, 2002 at 04:14:34AM -0800
On Sat, Nov 02, 2002 at 04:14:34AM -0800, H. Peter Anvin wrote:
> Matt Porter wrote:
> > On Sat, Nov 02, 2002 at 03:13:45AM -0500, Jeff Garzik wrote:
> >
> >>#4 - move mounting root to userspace
> >>
> >>People probably breathed a sigh of relief at patch #3, they will heave a
> >>bigger sigh for this patch :) This moves mounting of the root
> >>filesystem to early userspace, including getting rid of
> >>NFSroot/bootp/dhcp code in the kernel.
> >
> >
> > For those of us who only develop on nfsroot-based systems, does this
> > step include adding userspace network interface configuration and
> > bootp/dhcp client functionality to kinit? I want to assume that
> > "getting rid of NFSroot/bootp/dhcp" means moving that particular
> > functionality as part of this step. Just wondering what the
> > short-term impact will be on the poor embedded guys. :)
> >
>
> Probably not to kinit, but to early userspace, yes. There is no real
> reason to put everything into kinit, and a lot of these things we have
> already written up as part of the klibc bundle.
Ok, sounds good. I only mentioned kinit since Jeff's roadmap seemed
to be hazy on whether there was consensus on the single binary approach
versus several binaries. For maintenance sake, it seems that optional
separate binaries is the only way to go. Glad to hear that this is the
plan.
Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.
prev parent reply other threads:[~2002-11-02 23:01 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-02 8:13 [BK PATCHES] initramfs merge, part 1 of N Jeff Garzik
2002-11-02 8:18 ` Jeff Garzik
2002-11-02 8:42 ` Aaron Lehmann
2002-11-02 8:46 ` Jeff Garzik
2002-11-02 8:50 ` H. Peter Anvin
2002-11-02 19:01 ` Linus Torvalds
2002-11-02 12:07 ` H. Peter Anvin
2002-11-02 20:24 ` Alexander Viro
2002-11-02 23:46 ` Dave Cinege
2002-11-02 10:51 ` miltonm
2002-11-02 17:12 ` Matt Porter
2002-11-02 12:14 ` H. Peter Anvin
2002-11-02 20:37 ` an idling kernel Anu
2002-11-02 22:16 ` Jos Hulzink
2002-11-03 0:43 ` identifying the idling kernel and kernel hacking Anu
2002-11-04 19:16 ` an idling kernel Werner Almesberger
2002-11-02 20:37 ` [BK PATCHES] initramfs merge, part 1 of N Alexander Viro
2002-11-02 23:36 ` Matt Porter [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=20021102163620.A10451@home.com \
--to=porter@cox.net \
--cc=hpa@zytor.com \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
--cc=viro@math.psu.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox