From: Mark McLoughlin <markmc@redhat.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
kvm <kvm@vger.kernel.org>, Anthony Liguori <aliguori@us.ibm.com>,
Michael Tokarev <mjt@tls.msk.ru>,
Jesse Barnes <jbarnes@virtuousgeek.org>
Subject: Re: [PATCH] virtio: make PCI devices take a virtio_pci module ref
Date: Mon, 08 Dec 2008 13:03:29 +0000 [thread overview]
Message-ID: <1228741409.3609.32.camel@blaa> (raw)
In-Reply-To: <200812071852.08962.rusty@rustcorp.com.au>
On Sun, 2008-12-07 at 18:52 +1030, Rusty Russell wrote:
> On Saturday 06 December 2008 01:37:06 Mark McLoughlin wrote:
> > Another example of a lack of an explicit dependency causing problems is
> > Fedora's mkinitrd having this hack:
> >
> > if echo $PWD | grep -q /virtio-pci/ ; then
> > findmodule virtio_pci
> > fi
> >
> > which basically says "if this is a virtio device, don't forget to
> > include virtio_pci in the initrd too!". Now, mkinitrd is full of hacks,
> > but this is a particularly unusual one.
>
> Um, I don't know what this does, sorry.
>
> I have no idea how Fedora chooses what to put in an initrd; I can't think
> of a sensible way of deciding what goes in and what doesn't other than
> lists and heuristics.
Fedora's mkinitrd creates an initrd suitable to boot the machine you run
mkinitrd on, rather than creating an initrd suitable to boot any
machine.
So, it goes "ah, / is mounted from /dev/vda, we need to include
virtio_blk and it's dependencies". It does that in a generic way that
works well for most setups:
1) Find the device name (e.g. vda) below /sys/block
2) Follow the 'device' link to e.g. /sys/devices/virtio-pci/virtio1
3) Find the module need for this through either 'modalias' or the
'driver/module' symlink
4) Use modprobe to list any dependencies of that module
Clearly, virtio-pci won't be pulled in by any of this so we've added a
hack to say "oh, it's a virtio device, let's include virtio_pci just in
case".
It's not even the case that mkinitrd needs to know how to include the
the module for the bus, because in our case that's virtio.ko ... we've
pretty effectively hidden the the bus *implementation* from userspace.
I don't think this is worth wasting too much time fixing, that's why I'm
thinking we should just make virtio_pci built-in by default with
CONFIG_KVM_GUEST.
> But there really is no explicit dependency between virtio modules and
> virtio_pci. There just is for kvm/x86 at the moment, since that is how
> they use virtio. Running over another bus is certainly possible,
> though may never happen for x86 (happens today for s390).
Right, and in the case of both kvm/s390 and lguest the bus
implementation is built-in, not a module.
Cheers,
Mark.
next prev parent reply other threads:[~2008-12-08 13:05 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-04 12:44 [PATCH] virtio: make PCI devices take a virtio_pci module ref Mark McLoughlin
2008-12-04 22:46 ` Jiri Slaby
2008-12-05 9:02 ` Michael Tokarev
2008-12-05 13:17 ` Jiri Slaby
2008-12-05 14:55 ` Mark McLoughlin
2008-12-05 15:25 ` Jiri Slaby
2008-12-05 15:26 ` Greg KH
2008-12-05 18:30 ` Mark McLoughlin
2008-12-05 18:46 ` Greg KH
2008-12-08 11:49 ` [PATCH 1/2] virtio: add PCI device release() function Mark McLoughlin
2008-12-08 11:49 ` [PATCH 2/2] virtio: do not statically allocate root device Mark McLoughlin
2008-12-08 14:43 ` Anthony Liguori
2008-12-08 14:58 ` Mark McLoughlin
2008-12-05 18:33 ` [PATCH] virtio: make PCI devices take a virtio_pci module ref Mark McLoughlin
2008-12-05 15:43 ` Anthony Liguori
2008-12-05 17:22 ` Jiri Slaby
2008-12-05 18:36 ` Mark McLoughlin
2008-12-05 18:54 ` Anthony Liguori
2008-12-07 8:30 ` Rusty Russell
2008-12-07 13:36 ` Jiri Slaby
2008-12-05 0:13 ` Rusty Russell
2008-12-05 15:07 ` Mark McLoughlin
2008-12-07 8:22 ` Rusty Russell
2008-12-08 13:03 ` Mark McLoughlin [this message]
2008-12-08 14:46 ` Anthony Liguori
2008-12-09 16:41 ` Mark McLoughlin
2008-12-09 16:57 ` Anthony Liguori
2008-12-09 18:16 ` Kay Sievers
2008-12-10 9:49 ` Mark McLoughlin
2008-12-10 12:02 ` Kay Sievers
2008-12-09 22:25 ` Jesse Barnes
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=1228741409.3609.32.camel@blaa \
--to=markmc@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=jbarnes@virtuousgeek.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjt@tls.msk.ru \
--cc=rusty@rustcorp.com.au \
/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).