linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Pekka Enberg <penberg@kernel.org>
Cc: Michael Tokarev <mjt@tls.msk.ru>,
	Sasha Levin <levinsasha928@gmail.com>,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	Avi Kivity <avi@redhat.com>, Ingo Molnar <mingo@elte.hu>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] init: Support mounting devices from kernel command line
Date: Mon, 18 Jul 2011 14:44:06 -0500	[thread overview]
Message-ID: <1311018246.3531.32.camel@mulgrave> (raw)
In-Reply-To: <CAOJsxLFEBknf8m5k6XOG=by_-avWT5P+ScoBBHfO0sgZbo_kSA@mail.gmail.com>

On Mon, 2011-07-18 at 15:27 +0300, Pekka Enberg wrote:
> On Mon, Jul 18, 2011 at 3:15 PM, Michael Tokarev <mjt@tls.msk.ru> wrote:
> >>> In /tools/kvm we are interested in such feature to allow us to automatically
> >>> mount user home directory using virtio-9p from the host to the guest
> >>> filesystem under '/hostfs'.
> >
> > Can't the same be done within initramfs just as easy?
> >
> > Long time ago when initramfs first appeared the plan was to,
> > more or less, move all that mounting and root= handling
> > functionality to userspae, and here we're adding more
> > to kernel.  To me that sounds backwards...
> 
> Well, we can currently boot distro images using custom kernel combined
> with distro initramfs. I'm not sure how we can inject our mount point
> to initramfs as easily.

Actually, I think it can.  An initramfs is designed as an effective root
booting system that runs from /sbin/init, does it's stuff like driver
loading and device finding, mounts the real root and pivots to it before
executing /sbin/init.

It strikes me, therefore, that it's fairly easy to insert another initrd
at the beginning of that process, so you alter the kernel to boot with
virt_initrd as the initramfs.  It would prepare all your mount points
(or muck with the parameters so they'd get mounted by the next initrd)
and load any virt drivers, then take the next initrd into a tempfs,
pivot to it and exec /sbin/init.

That would seem to work without needing any kernel patches at all.

James

> I don't think it's backwards progress but then again, I don't really
> use initramfs or modules for that matter so maybe I'm just old
> fashioned.



      reply	other threads:[~2011-07-18 19:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1310979967-13470-1-git-send-email-levinsasha928@gmail.com>
2011-07-18 11:55 ` [PATCH] init: Support mounting devices from kernel command line Pekka Enberg
2011-07-18 12:15   ` Michael Tokarev
2011-07-18 12:27     ` Pekka Enberg
2011-07-18 19:44       ` James Bottomley [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=1311018246.3531.32.camel@mulgrave \
    --to=james.bottomley@hansenpartnership.com \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=levinsasha928@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mjt@tls.msk.ru \
    --cc=penberg@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).