
*	Use new #define _DEFAULT_SOURCE to build OVT.
	
	glibc-2.20 has deprecated the _BSD_SOURCE and _SVID_SOURCE
	macros.  Starting with glibc-2.19 _DEFAULT_SOURCE is
 	recommended.  Keep the old macros because someone might
 	want to build open-vm-tools with an older glibc version.
	
	With glibc-2.20 VGAuthLog.c was picking the POSIX
 	definition for strerror_r that returns int type.
	That does not work with glibc-2.2, which has only one
 	definition with return type char *.  For better
 	compatibility with various glibc versions, use the
	_GNU_SOURCE definition of strerror_r that returns char *.
	
*	Fix a compilation error in toolboxcmd-shrink.c with gcc 5.0.1.

	Building open-vm-tools for Fedora 22 hit a compilation
 	error with gcc 5.0.1.

	Also remove some redundant code. ShrinkGetMountPoints()
	calls ShrinkGetWiperState() and handles the
 	WIPER_UNAVAILABLE and WIPER_DISABLED cases. The call to
 	ShrinkGetWiperState() is redundant because wiper state
	will always be WIPER_ENABLED.
	
*	Fix the compiler version check and include mul64.h.
	
	The compiler check was intended to be >= GCC 4.4, but it
	was insisting that the major and minor version numbers
	of GCC both be >= 4, so it was breaking on Fedora 22,
 	which has GCC 5.1.1, and for a user who was building with
 	GCC 4.3.
	
	For old compilers we need to provide mul64.h, so include
	it in open-vm-tools.
	
*	Retry sending vmbackup event with elevated privileges.
	
	A privilege check on the host side was implemented in
	ESXi 5.5. Due to this change, once guest/Toolsd sends
	iopl_elevation capability (RPC msg
	"tools.capability.iopl_elevation") to an ESXi 5.5 host,
	it requires guest to elevate the privileges before the
	guest sends vmbackup event. Linux Tools version 9.4.x
	sends this capability and enables this behavior on the
	host.  Tools version 9.10.0 does not send iopl_elevation
	capability and does not require privilege elevation.
	Therefore, in order to workaround the host behavior, we
	retry sending the vmbackup event after elevating the guest
	privileges. To avoid doubling the RPC messages from
 	Toolsd, we also cache the last failure result from the
	unprivileged attempt for the duration of current vmbackup
	operation.
	
*	vSock changes to prepare for FreeBSD
	
	Add support to header files for FreeBSD.  For now just
	add some stubs that return errors.
	 
*	add a -h option to vgauth

	vgauth is not normally run from a command line, but
	add a -h option to provide minimal documentation.
	
*	Bump Tools version to 9.10.2 for open-vm-tools release.
	
*	Workaround NFS open bug by retrying on ESTALE
	
	RFC 1341775 uncovered an NFS client open race which causes 
	open to fail with ESTALE if there is another host trying to
	atomically swap the file at the same time. This causes the file to
	be unlinked which might cause the thread trying to open it (for 
	acquiring lock) to fail with ESTALE. 

	Implement a very simple fix which retries for 3 seconds
	upon getting ESTALE. 
 
*	Fix the HGFS protocol opcode to differentiate headers
	
	For differentiating the older HgfsRequest and the new
	HgfsHeader structures sent in an HGFS packet, the old
	header opcode is set to 0xff using HGFS_V4_LEGACY_OPCODE.
	
	This should have been made a specific value of the HGFS
	opcode enum and named for what it really means, but the
	enum type could clash with the HGFS_V4_LEGACY_OPCODE by
	accident if enough values are added.
	
	There is a potential issue with the newer HgfsHeader
	object where it overlays the old HgfsRequest op field.
	The new header tries to break the field into the first
	byte and save the remaining 3 bytes for a different use.
 	However, this cannot be done as the current and shipping
 	HGFS server code uses the HgfsRequest and op field
	(4 bytes) to verify the value is 0xFF. If this is a match
 	then it is deemed that the packet has the new header. If
 	the client tried to use any of the new header's reserved2
 	fields (overlayed with part of the old header op field)
	then the HGFS server test for a new header would fail to
 	match.
	
	Fixed the HgfsHeader opcode fields to actually be the
	correct HgfsOp type.

	Removed the define for HGFS_V4_LEGACY_OPCODE and made it
	part of the opcode enum to ensure correct type checking.

	Added an assert on compile to ensure that the HGFS opcode
	values don't encroach on the invalid opcode used to
	determine the header type.

	Renamed the HGFS_V4_LEGACY_OPCODE to conform with the
	existing enum values and state exactly what its meaning
	is: HGFS_OP_NEW_HEADER.
	
	Now the 4 bytes cannot be used for anything but the
	protocol opcode new header value. This also corrects any
	strict typing by compilers for building open vm tools in
	newer guest operating systems.
	
*	Thaw filesystems when the snapshot commit message to VMX fails.  
	
	If it takes a long time to freeze filesystems, VMX may
	timeout the snapshot operation so the commit fails.
	After this happens, thaw the frozen filesystems.
	
*	open-vm-tools: fixes to build on FreeBSD 10
	
	Various fixes to make open-vm-tools build on FreeBSD:

	- disable vsock for OSes other than Linux
	- define CheckSanity only ifdef VMX86_DEBUG
	- make build of hgfsUriPosix depend on having gtkmm,
	  and enable on FreeBSD
	- xferlogs.c does not need wchar.h

	Instructions for building on FreeBSD:

	1. Install gcc48 with 'pkg install gcc'
	2. Install build dependencies:
	   glib libdnet libXinerama libXrandr gtk2 gtkmm24
	3. autoreconf -i --force
	4. env CC=gcc48 CFLAGS=-Wl,-rpath=/usr/local/lib/gcc48
	       CPPFLAGS="-I/usr/local/include/"
	       LIBS="-L/usr/local/lib" 
	       ./configure --without-kernel-modules
	       --without-xmlsecurity --without-icu
	       --disable-vgauth --disable-grabbitmqproxy
	       --disable-deploypkg
	5. make
	 
*	Don't build vmxnet driver for Linux >= 3.3

	The vmxnet driver does not build for Linux kernel
	versions >= 3.3.

*	Don't build HGFS kernel driver for Linux >= 3.17.0

	The HGFS kernel component is old and has many changes missing
	to support newer Linux kernel releases.  There will be a newer
	update coming which will include all of the changes necessary
	for newer Linux kernels to be supported.

	For now, we are limiting the building of the current HGFS
	kernel client to Linux kernels 3.17.0 and earlier for this
	release of open-vm-tools. This will allow the build of the
	open-vm-tools package to complete on newer kernel versions.

