linux-kernel - Re: [PATCH] VMware Balloon: rename module

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTinokTUuShVEokYyJApj26CBD-q+xma_55rgdZEM@mail.gmail.com>
Date:	Thu, 16 Sep 2010 20:13:32 -0400
From:	Chetan Loke <chetanloke@...il.com>
To:	Dmitry Torokhov <dtor@...are.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"pv-drivers@...are.com" <pv-drivers@...are.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
Subject: Re: [PATCH] VMware Balloon: rename module

On Thu, Sep 16, 2010 at 7:23 PM, Dmitry Torokhov <dtor@...are.com> wrote:
> Hi Chetan,
Hi

>> > In an effort to minimize customer confusion we want to unify naming
>> > convention for VMware-provided kernel modules. This change renames
>> > the balloon driver from vmware_ballon to vmw_balloon.
>>
>> What will vmtools name its vmware_balloon driver to? vmw_balloon, correct?
>
> That is the plan.

I will have to change my scripts/iso's if there's a mismatch. If
there's a mismatch then will we end up w/ 2 drivers?
Or will vmtools cleanup the past residue?
We prep'd a 2.6.35 iso. Now while updating I will have to wrap a
special case to account for balloon-renaming.
The case that I'm worried about is this:
1) 2.6.35 - vmware_balloon
2) upgrade kernel - now vmw_balloon
3) install vmtools  - a new vmware_balloon(?) if this version of
vmtools didn't pick up the change?
Is there a workaround?

Sorry, not being a pain but we have had some tough time with
vmtool-upgrades+udev+vmxnet and vnic addition/deletion recently.

>
>>
>> > +   vmballoon_wq = create_freezeable_workqueue("vmmemctl");
>>
>> minor change - vmware_vmmemctl?
>
> I do not think this needs to be changed; it does not have to match
> the module name, plus, given Tejun's changes, it will all be generic
> [worker/u:X] soon anyway.
>
ok.

>>
>> side note - is it possible to extend the balloon driver to get a
>> notification on other events? like CPUs, NICs? Just an event is what
>> I'm looking for. No action need to be taken in the guest.
>
> No, balloon driver should be limited to ballooning. I think the data
> you are looking for can be retrieved via GuestSDK (and I believe we
> are adding balloon_target to the available data).
>

No. I think the guestSDK provides the guest, it's personal view of the
world, no?
http://www.vmware.com/support/developer/guest-sdk/

ballooning is an indirect hint that an external event has happened
within the hypervisor. I'm looking for similar external events.
guestSDK gives nothing. Because right now there is now way for a
vmware-guest to cooperate or be a good citizen if it
doesn't know what's happening in the esx-hypervisor. Now whether to
add these events in the balloon driver is another thing.
A separate driver is ok too.

> Thanks.
> Dmitry

thanks
cloke
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/