Thread: duplicate hgfs.h, block.h,stubs.h includes in archive....

Status: Beta

Brought to you by: andycking, dsouders, dtor, dynofu, and 3 others

open-vm-tools-devel

duplicate hgfs.h, block.h,stubs.h includes in archive....

From: Olivier L. <oli...@ce...> - 2009-05-18 14:07:01

Trying to minimize the number of includes to put in the dkms build tree I'm 
trying to create, I've found that there are 2 hgfs.h , 2 block.h and 2 stubs.h 
includes that are identical except for the top comment (tipicaly the license). 
Is it normal?

modules/linux/vmhgfs/hgfs.h is GPL v2
lib/include/hgfs.h is LGPL v2.1

modules/linux/vmblock/linux/block.h is GPL v2
vmblock-fuse/block.h is LGPL v2.1

modules/linux/vmblock/linux/stubs.h is GPL v2
vmblock-fuse/stubs.h is LGPL v2.1

Aside that, they are strictly identical...

-- 
	Olivier LAHAYE
	CEA Saclay
	DRT-LIST-DETECS-SSTM

Re: duplicate hgfs.h, block.h,stubs.h includes in archive....

From: Marcelo V. <mv...@vm...> - 2009-05-19 00:40:31

Hi Olivier,

Olivier LAHAYE wrote:
> Trying to minimize the number of includes to put in the dkms build tree I'm 
> trying to create, I've found that there are 2 hgfs.h , 2 block.h and 2 stubs.h 
> includes that are identical except for the top comment (tipicaly the license). 
> Is it normal?
> 
> modules/linux/vmhgfs/hgfs.h is GPL v2
> lib/include/hgfs.h is LGPL v2.1
> 
> modules/linux/vmblock/linux/block.h is GPL v2
> vmblock-fuse/block.h is LGPL v2.1
> 
> modules/linux/vmblock/linux/stubs.h is GPL v2
> vmblock-fuse/stubs.h is LGPL v2.1
> 
> Aside that, they are strictly identical...

Yes, the files are identical except for the license. This is one of the things I 
worked on the past couple of months and, in the next code refresh (sometime this 
week) most of these duplications should be gone. (In fact, the only one I see 
now is hgfs.h, which apparently I missed.)

So at least it should be easier to choose which file to package since there 
should be only one from now on. :-) (The files will be licensed under LGPL and, 
where needed, CDDL and / or BSD; I'm assuming that LGPL is fine for use in the 
kernel module code which is licensed under the GPL - all these licenses make my 
head spin sometimes).

About your other question about what files to package, after all this cleanup it 
does become a little bit trickier to package modules for use with dkms; 
basically, what you'll have to do is:

. place all shared headers either on the module's dir directly, or under a 
"shared" directory under the module's source dir
. place all the "autoconf" stuff under "shared/autoconf" under the module's 
source dir
. copy any shared sources to the module's source dir (for example, 
lib/misc/dbllnklst.c which is used by a few modules).

Also, you shouldn't define OVT_SOURCE_DIR when building through dkms (in case 
you're wondering why that's used in modules/Makefile.am). That variable changes 
the behavior of the makefiles to use the shared stuff in the open-vm-tools 
package, which is not what you want for dkms.

We do something similar when we package these modules with the Tools we ship 
with Workstation or other VMware products, so if you want more information about 
what the directory structure for building different modules "stand alone" looks 
like, feel free to ask.

-- 
- Marcelo

Re: duplicate hgfs.h, block.h,stubs.h includes in archive....

From: Olivier L. <oli...@ce...> - 2009-05-25 14:22:32

Attachments: open-vm-tools-2009.05.22-167859.patch vmtoolsd

Hi Marcelo,

I've worked on the new release (build 167859) and I'm still having great 
difficulties to package open-vm-tools.

Here are the problems.

1st of all I had to do a few patch for the whole stuff to build correctly (see 
attachment). Basicaly I had to patch configure.ac (DOT=/usr/bin instead of 
DOT=dot). Then I had to patch docs/api/Makefile.am to add the -e 
's,##{PROJECT_NAME}##,@PACKAGE_STRING@,' line and then I had to fix 
lib/wiper/wiperPosix.c to handle fgets return.

2nd, lib/include/err.h has the same name as /usr/include.err.h
Should the file be packaged in the open-vm-tools-devel? if yes, should the 
includes go to /usr/include or /usr/include/vmware ?

3rd I must admit that I'm a little bit lost in finding what files should be 
packaged and what files are only relevant to build open-vm-tools.
Basicaly, which includes should be part of open-vm-tools-devel:/usr/include, 
which files should be part of dkms-open-vm-tools (that are not in open-vm-
tools)

I've also created an init file (/etc/init.d/vmtoolsd) that should be LSB 
compatible (see attachment).

Aside that, except using the ./configure script, I'm totaly unfamiliar with 
autotools, and thus I'm realy unable to go beyond a few very basic patch in 
.ac and .am files, thus I'm afraid I won't be able to setup the "autoconf stuff" 
in the shared dir.
I've notices in the modules dir that the Makefile has different behaviours 
depending OVT_SOURCE_DIR is defined or not. I've also noticed that the 
dkms.conf file uses the standard Makefile. Then what is the purpose of 
Makefile.kernel file?

Best regards,

Olivier.



Le mardi 19 mai 2009 02:30:01 Marcelo Vanzin, vous avez écrit :
> About your other question about what files to package, after all this
> cleanup it does become a little bit trickier to package modules for use
> with dkms; basically, what you'll have to do is:
>
> . place all shared headers either on the module's dir directly, or under a
> "shared" directory under the module's source dir
> . place all the "autoconf" stuff under "shared/autoconf" under the module's
> source dir
> . copy any shared sources to the module's source dir (for example,
> lib/misc/dbllnklst.c which is used by a few modules).
>
> Also, you shouldn't define OVT_SOURCE_DIR when building through dkms (in
> case you're wondering why that's used in modules/Makefile.am). That
> variable changes the behavior of the makefiles to use the shared stuff in
> the open-vm-tools package, which is not what you want for dkms.
>
> We do something similar when we package these modules with the Tools we
> ship with Workstation or other VMware products, so if you want more
> information about what the directory structure for building different
> modules "stand alone" looks like, feel free to ask.

-- 
	Olivier LAHAYE
	CEA Saclay
	DRT-LIST-DETECS-SSTM

Re: duplicate hgfs.h, block.h,stubs.h includes in archive....

From: Dominique L. <Dom...@TM...> - 2009-05-25 14:42:10

Attachments: open-vm-tools.spec

Olivier,

>>> On 5/25/2009 at 16:03, Olivier LAHAYE <oli...@ce...> wrote: 

> hen I had to fix 
> lib/wiper/wiperPosix.c to handle fgets return.

Had that too (I'm doing openSUSE packges). Sent my patch in also.

> 3rd I must admit that I'm a little bit lost in finding what files should be 
> packaged and what files are only relevant to build open-vm-tools.
> Basicaly, which includes should be part of open-vm-tools-devel:/usr/include, 
> which files should be part of dkms-open-vm-tools (that are not in open-vm-
> tools)

The wiki gives quite some overview of what to package and where to put it. Most of the things are done correct by now using make install (I remember
a time this did not do anything useful).
http://open-vm-tools.wiki.sourceforge.net/Packaging

> 
> I've also created an init file (/etc/init.d/vmtoolsd) that should be LSB 
> compatible (see attachment).

Maybe you can have a look what I all did in the RPM for openSUSE? Might help you save some hours. We're shipping it since openSUSE 11.1, so the
packages are proven by now to work (even though the two last releases were not pushed out. Previous one had issues with Drag'n'Drop handler and the
new one is not yet tested by me). I attach you for reference the RPM we use for the openSUSE packages (it creates KMPs (Kernel Module Packages). The
complete SRPMS are downloadable at: http://download.opensuse.org/repositories/home:/dimstar/openSUSE_11.1/src/

Dominique

open-vm-tools packaging [Was: Re: duplicate hgfs.h, block.h, stubs.h includes in archive....]

From: Olivier L. <oli...@ce...> - 2009-05-25 15:24:40

Attachments: open-vm-tools.spec

Dominique, thanks a lot for your tips.

See my comments below.

> The wiki gives quite some overview of what to package and where to put it.
> Most of the things are done correct by now using make install (I remember a
> time this did not do anything useful).
> http://open-vm-tools.wiki.sourceforge.net/Packaging
Yes, I know this URL, unfortunately, I did not find any usefull tips regarding 
includes and devel parts.
It looks like some .c files are shared between modules and tools, that some .h 
files are in tools build structure, but also used by some mudules

For now I have an open-vm-tools that works for the userlan tools and system.
what I'm stuck with is the foillowing:
- Put modules in a dkms package that build modules at boot if the kernel has 
been updated
- Create a working open-vm-tools-devel package that permit developpements of 
new tools (tuypicaly would contain includes and .so files)

> Maybe you can have a look what I all did in the RPM for openSUSE? Might
Thanks a lot for your help, I had a 1st look at your RPM spec file which looks 
very interresting (see mine attached).
Unfortunately I don't quite understand the module part. As a distribution 
owner I understand that you create a binary package for the modules right?
I assume that %suse_kernel_module_package -n vmware-guest -p %{SOURCE98} xen 
um does all the magic ;-)
Although, I'm unable to follow this way as I'm not a Mandriva developper and 
thus I'm unable to follow thightly all new kernel releases. If a user updates 
its kernel, then I'll loose ability to connect it its vm and I'll have to 
rebuild modules by hand.
Thus I'm forced to go for the dkms way until Mandriva includes open-vm-tools 
in its main release tree.

Maybe one day all thoses modules will go into the standard linux kernel.... 
who knows?

Olivier.
-- 
	Olivier LAHAYE
	CEA Saclay
	DRT-LIST-DETECS-SSTM

open-vm-tools packaging [Was: Re: duplicate hgfs.h, block.h,stubs.h includes in archive....]

From: Dominique L. <Dom...@TM...> - 2009-05-25 15:40:14

Olivier,

>>> On 5/25/2009 at  5:24 , Olivier LAHAYE <oli...@ce...> wrote:

>> http://open-vm-tools.wiki.sourceforge.net/Packaging 
> Yes, I know this URL, unfortunately, I did not find any usefull tips 
> regarding 
> includes and devel parts.
> It looks like some .c files are shared between modules and tools, that some 
> .h 
> files are in tools build structure, but also used by some mudules

I don't think the tools are actually ready to be extended by 3rd-parties. As such, I would not bother to much installing the devel packages.
Even the fact with new kernels might be rather tricky: the modules are known to break with every single kernel release. Just now I'm stuck as
openSUSE is moving to 2.6.30, but the modules do not yet compile on this kernel. Shame.

> - Put modules in a dkms package that build modules at boot if the kernel has 
> been updated
I see, as your package is not as closely linked, it's probably the only way to go.

> - Create a working open-vm-tools-devel package that permit developpements of 
> new tools (tuypicaly would contain includes and .so files)

As stated above: I don't think the tools are solid enough to encourage any 3rd party to develop on them out of the tree. Thus providing -devel
package is probably not yet a good idea anyhow.

>> Maybe you can have a look what I all did in the RPM for openSUSE? Might
> Thanks a lot for your help, I had a 1st look at your RPM spec file which 
> looks 
> very interresting (see mine attached).
> Unfortunately I don't quite understand the module part. As a distribution 
> owner I understand that you create a binary package for the modules right?
> I assume that %suse_kernel_module_package -n vmware-guest -p %{SOURCE98} xen 
> um does all the magic ;-)
> Although, I'm unable to follow this way as I'm not a Mandriva developper and 

yes, indeed: this does a lot of magic. It creates module packages for all different kernel flavors (different compiler options basically) and creates
one RPM per flavor. XEN being excluded (I doubt that anybody is running a vmware inside a xen host or guest.. would not make to much sense). So yes,
being close tight to the distribution is a big advantage here.

> 
> thus I'm unable to follow thightly all new kernel releases. If a user 
> updates 
> its kernel, then I'll loose ability to connect it its vm and I'll have to 
> rebuild modules by hand.
> Thus I'm forced to go for the dkms way until Mandriva includes open-vm-tools 
> in its main release tree.

You should encourage them to do so early. Less wasted time for you. 

> 
> Maybe one day all thoses modules will go into the standard linux kernel.... 
> who knows?

Oh.. THAT would be awesome. It would also finally stop us from being without running vmware (workstation/player/tools) with every new kernel hitting
the shelfs. But I'm not sure I'm not to old already to still survive that day (hey.. I'm only 32.. but who knows how long THIS is going to take).

Dominique