From: Dmitry Torokhov <dtor@vmware.com>
To: Alexander Clouter <alex@digriz.org.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] VMware balloon: force compiling as a module
Date: Tue, 29 Jun 2010 09:39:00 -0700 [thread overview]
Message-ID: <201006290939.00988.dtor@vmware.com> (raw)
In-Reply-To: <vcnof7-b9p.ln1@chipmunk.wormnet.eu>
Hi Alexander,
On Tuesday, June 29, 2010 01:27:43 am Alexander Clouter wrote:
> Dmitry Torokhov <dtor@vmware.com> wrote:
> > VMware Tools installer requires the upstream driver to be compiled
> > as a module in order to detect its presence and avoid installing
> > our own version on top of it. To avoid surprises with 2 versions
> > of the driver being installed and fighting with each other, let's
> > force the driver to be compiled as a module unless user selects
> > CONFIG_EMBEDDED.
>
> *barf*
>
> This surely is a problem in the installer and not the kernel? Can you
> not nosey around in /sys/class/misc or where-ever your driver appears?
The driver does not "appear" anywhere at the moment as it does not export
any interfaces to userland. It only communicates with the hypervisor.
Unfortunately the kernel, with the exception of module parameters which
this driver does not have at the moment, does not populate
/sys/module/<modulename> for modules built into the kernel and so
installer can not rely on this data. Also, the module might be disabled
(blacklisted) by the system administrator and thus being absent from the
kernel. In such scenario we also so not want to install our version of the
driver.
> If it does not, then I would probably suggest a patch to your balloon
> driver that dumps some details in there, including module version
> information.
>
> Eugh.
Exactly, eugh. I do not believe that dumping some unnecessary data in
sysfs is better than making driver a module.
Also, besides the installer logic, we prefer having the driver being
compiled by default as a module so that we can deliver truly urgent
fixes to customers without need of recompiling the kernel/wait for
distribution to roll out the updates/needing to reboot the box.
Thanks.
--
Dmitry
next prev parent reply other threads:[~2010-06-29 16:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-28 23:00 [PATCH] VMware balloon: force compiling as a module Dmitry Torokhov
2010-06-29 8:27 ` Alexander Clouter
2010-06-29 16:28 ` Bruno Prémont
2010-06-29 16:40 ` Dmitry Torokhov
2010-07-01 22:18 ` Andrew Morton
2010-07-01 22:31 ` Dmitry Torokhov
2010-07-01 22:43 ` Andrew Morton
2010-07-01 22:59 ` Dmitry Torokhov
2010-07-02 8:09 ` Alexander Clouter
2010-06-29 16:39 ` Dmitry Torokhov [this message]
-- strict thread matches above, loose matches on Subject: below --
2010-06-30 18:42 Chetan Loke
2010-06-30 19:27 ` Dmitry Torokhov
2010-06-30 21:26 ` Chetan Loke
2010-06-30 21:39 ` Dmitry Torokhov
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=201006290939.00988.dtor@vmware.com \
--to=dtor@vmware.com \
--cc=alex@digriz.org.uk \
--cc=linux-kernel@vger.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