VMware balloon: force compiling as a module

PATCH In review Dmitry Torokhov 4 participants 10 messages Jun 28, 2010 – Jul 2, 2010 Char and misc drivers

Share & tools

Dmitry Torokhov

author

2010-06-28 23:00 UTC #0 lore raw

PATCH 1/1 VMware balloon: force compiling as a module

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.

Signed-off-by Dmitry Torokhov <[email protected]>

---

Andrew,

Please consider forwarding this to Linus in your next batch.

Thanks,
Dmitry

 drivers/misc/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

drivers/misc/Kconfig +1 -1

index 26386a9..bb5b6ea 100644
@@ -339,7 +339,7 @@ config TI_DAC7512
 
 config VMWARE_BALLOON
 	tristate "VMware Balloon Driver"
-	depends on X86
+	depends on X86 && (EMBEDDED || m)
 	help
 	  This is VMware physical memory management driver which acts
 	  like a "balloon" that can be inflated to reclaim physical pages

Signature · 1 line

1.7.0

Alexander Clouter

2010-06-29 08:35 UTC #1 lore raw

Quoted 8 lines · Dmitry Torokhov

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? 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.

Signature · 3 lines

Alexander Clouter
.sigmonster says: Who goeth a-borrowing goeth a-sorrowing.
                  		-- Thomas Tusser

Bruno Prémont

2010-06-29 16:29 UTC #2 lore raw

Quoted 11 lines · On Tue, 29 June 2010 Alexander Clouter <[email protected]> wrote:

Quoted 8 lines · Dmitry Torokhov
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*

Quoted 7 lines

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? 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.

In addition, the installer may check under /sys/module/ for it (as for any/most code that can be built as a module), even for built-in code. (if balloon driver does not show up there when built-in it would be better to get it to show up there)

Bruno

Dmitry Torokhov

author

2010-06-29 16:40 UTC #3 lore raw

Quoted 17 lines · Bruno Prémont

Quoted 16 lines · On Tue, 29 June 2010 Alexander Clouter <[email protected]> wrote:
Quoted 6 lines · Dmitry Torokhov
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? 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.

Quoted 7 lines

Quoted 1 line
Eugh.
In addition, the installer may check under /sys/module/ for it (as for any/most code that can be built as a module), even for built-in code. (if balloon driver does not show up there when built-in it would be better to get it to show up there)

When driver is built-in the only thing exported in /sys/module/XXX are module parameters.

We also need to handle scenario when module is not loaded into the kernel.

Thanks.

Signature · 1 line

Dmitry

Andrew Morton

2010-07-01 22:19 UTC #4 lore raw

Quoted 26 lines · On Tue, 29 Jun 2010 09:40:38 -0700 Dmitry Torokhov <[email protected]> wrote:

Quoted 17 lines · Bruno Pr__mont
Quoted 16 lines · On Tue, 29 June 2010 Alexander Clouter <[email protected]> wrote:
Quoted 6 lines · Dmitry Torokhov
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? 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.
Quoted 7 lines
Quoted 1 line
Eugh.
In addition, the installer may check under /sys/module/ for it (as for any/most code that can be built as a module), even for built-in code. (if balloon driver does not show up there when built-in it would be better to get it to show up there)

Quoted 6 lines

When driver is built-in the only thing exported in /sys/module/XXX are module parameters.
We also need to handle scenario when module is not loaded into the kernel.

- check for the /sys/module directory.

- if that failed, modprobe the driver

- if that failed, error out

The patch really is pretty icky. Adding restrictions to kernel configuration to work around problems in some installer program?

Dmitry Torokhov

author

2010-07-01 22:31 UTC #5 lore raw

Quoted 28 lines · Andrew Morton

On Tue, 29 Jun 2010 09:40:38 -0700
Quoted 25 lines · Dmitry Torokhov
Quoted 23 lines · Bruno Pr__mont
Quoted 10 lines · On Tue, 29 June 2010 Alexander Clouter <[email protected]> wrote:
Quoted 6 lines · Dmitry Torokhov
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*
Quoted 7 lines
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? 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.
In addition, the installer may check under /sys/module/ for it (as for any/most code that can be built as a module), even for built-in code. (if balloon driver does not show up there when built-in it would be better to get it to show up there)

Quoted 7 lines

Quoted 5 lines
When driver is built-in the only thing exported in /sys/module/XXX are module parameters.
We also need to handle scenario when module is not loaded into the kernel.
- check for the /sys/module directory.

Empty.

Quoted 3 lines

- if that failed, modprobe the driver

Succeeds since the driver name changed (we renamed it to vmware_balloon before submitting into mainline to avoid confusion based on our experience with pvscsi; the existing one in the wild is called vmmemctl).

Now we have 2 drivers fighting. There is no backing device and so driver core will not save us by refusing to bind to already claimed device.

Quoted 4 lines

- if that failed, error out
The patch really is pretty icky. Adding restrictions to kernel configuration to work around problems in some installer program?

It is probably not the prettiest patch, I agree, but users still have an option of building this stuff in if they care that much (CONFIG_EMBEDDED).

Thanks.

Signature · 1 line

Dmitry

Andrew Morton

2010-07-01 22:44 UTC #6 lore raw

Quoted 32 lines · On Thu, 1 Jul 2010 15:31:50 -0700 Dmitry Torokhov <[email protected]> wrote:

Quoted 31 lines · Andrew Morton
On Tue, 29 Jun 2010 09:40:38 -0700
Quoted 28 lines · Dmitry Torokhov
Quoted 17 lines · Bruno Pr__mont
Quoted 16 lines · On Tue, 29 June 2010 Alexander Clouter <[email protected]> wrote:
Quoted 6 lines · Dmitry Torokhov
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? 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.
Quoted 6 lines
Quoted 1 line
Eugh.
In addition, the installer may check under /sys/module/ for it (as for any/most code that can be built as a module), even for built-in code. (if balloon driver does not show up there when built-in it would be better to get it to show up there)
When driver is built-in the only thing exported in /sys/module/XXX are module parameters.

Quoted 6 lines

Quoted 4 lines
Quoted 2 lines
We also need to handle scenario when module is not loaded into the kernel.
- check for the /sys/module directory.
Empty.

But the presence of the empty /sys/module/vmware_balloon tells you that the driver is loaded?

Confused.

Quoted 10 lines

Quoted 3 lines
- if that failed, modprobe the driver
Succeeds since the driver name changed (we renamed it to vmware_balloon before submitting into mainline to avoid confusion based on our experience with pvscsi; the existing one in the wild is called vmmemctl).
Now we have 2 drivers fighting. There is no backing device and so driver core will not save us by refusing to bind to already claimed device.

If vmware_balloon is present in /sys/modules or is loaded, don't load vmmemctl. And vice versa.

I dunno - it's silly for me to sit here proposing solutions. it's better that you do it!

Dmitry Torokhov

author

2010-07-01 23:00 UTC #7 lore raw

Quoted 38 lines · Andrew Morton

On Thu, 1 Jul 2010 15:31:50 -0700
Quoted 35 lines · Dmitry Torokhov
Quoted 34 lines · Andrew Morton
On Tue, 29 Jun 2010 09:40:38 -0700
Quoted 30 lines · Dmitry Torokhov
Quoted 17 lines · Bruno Pr__mont
Quoted 16 lines · On Tue, 29 June 2010 Alexander Clouter <[email protected]> wrote:
Quoted 6 lines · Dmitry Torokhov
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? 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.
Quoted 6 lines
Quoted 1 line
Eugh.
In addition, the installer may check under /sys/module/ for it (as for any/most code that can be built as a module), even for built-in code. (if balloon driver does not show up there when built-in it would be better to get it to show up there)
When driver is built-in the only thing exported in /sys/module/XXX are module parameters.
We also need to handle scenario when module is not loaded into the kernel.

Quoted 8 lines

Quoted 3 lines
Quoted 1 line
- check for the /sys/module directory.
Empty.
But the presence of the empty /sys/module/vmware_balloon tells you that the driver is loaded?
Confused.

No, unfortunately a kernel module that does not use module parameters is invisible when it is built in. If you check your box you will most likely not see /sys/module/evdev, /sys/module/input, and so forth.

Quoted 8 lines

Quoted 8 lines
Quoted 2 lines
- if that failed, modprobe the driver
Succeeds since the driver name changed (we renamed it to vmware_balloon before submitting into mainline to avoid confusion based on our experience with pvscsi; the existing one in the wild is called vmmemctl).

Quoted 8 lines

Quoted 2 lines
Now we have 2 drivers fighting. There is no backing device and so driver core will not save us by refusing to bind to already claimed device.
If vmware_balloon is present in /sys/modules or is loaded, don't load vmmemctl. And vice versa.
I dunno - it's silly for me to sit here proposing solutions. it's better that you do it!

Unfortunately I do not have a good solution at the moment. I guess we'll have to work with distributions to make sure they keep it as a module (it also makes most sense for them since not everyone runs on our platform).

Thanks.

Signature · 1 line

Dmitry

Alexander Clouter

2010-07-02 09:08 UTC #8 lore raw

Quoted 7 lines · Dmitry Torokhov

Quoted 7 lines
Quoted 3 lines
Now we have 2 drivers fighting. There is no backing device and so driver core will not save us by refusing to bind to already claimed device.
If vmware_balloon is present in /sys/modules or is loaded, don't load vmmemctl. And vice versa.

Quoted 8 lines

Quoted 2 lines
I dunno - it's silly for me to sit here proposing solutions. it's better that you do it!
Unfortunately I do not have a good solution at the moment. I guess we'll have to work with distributions to make sure they keep it as a module (it also makes most sense for them since not everyone runs on our platform).

I cannot seriously believe you are considering a viable solution is "everyone[1] must abide by these rules otherwise our installer might barf". The only benefactor of this patch is your installer and the effect is an undocumented and peculiar constraint on a kernel module.

Seriously, add sometime so that you get something in /sys/modules (maybe it's time for something in /sys/class?) or maybe do something so that you have: VMWARE_BALLOON_CMD(STATUS, ...) where the guest can say if there is already something ballooning for it. Surely the guest should be aware if there is more than one balloon driver at play?

I think a friend of mine summed it up rather well: "Fixing the kernel instead of fixing the VMWare installer is an inspired move".

Cheers

[1] the dropdown menu on distrowatch lists 319 distrubutions

Signature · 2 lines

Alexander Clouter
.sigmonster says: May the bluebird of happiness twiddle your bits.

Dmitry Torokhov

author

2010-06-29 16:39 UTC #9 lore raw

In reply to Alexander Clouter

Hi Alexander,

Quoted 8 lines · Alexander Clouter

Quoted 6 lines · Dmitry Torokhov
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.

Quoted 4 lines

*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.

Quoted 5 lines

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.

Signature · 1 line

Dmitry