← Back to branch summary

~n-muench/ubuntu/oneiric/open-vm-tools/open-vm-tools.fix-836277

« back to all changes in this revision

Viewing changes to lib/include/hgfs.h

  • Committer: Bazaar Package Importer
  • Author(s): Devid Antonio Filoni
  • Date: 2008-08-15 21:21:40 UTC
  • mfrom: (1.1.1 upstream)
  • Revision ID: james.westby@ubuntu.com-20080815212140-05fhxj8wroosysmj
Tags: 2008.08.08-109361-1ubuntu1
https://launchpad.net/bugs/258393
* Merge from Debian unstable (LP: #258393), remaining Ubuntu change:
  - add ubuntu_toolchain_FTBFS.dpatch patch, fix FTBFS
* Update ubuntu_toolchain_FTBFS.dpatch patch for the new version.

Show diffs side-by-side

added added

removed removed

Lines of Context:
lib/include/hgfs.h
39
39
#include "includeCheck.h"
40
40
#include "vm_assert.h"
41
41
 
 
42
/*
 
43
 * Maximum number of pages to transfer to/from the HGFS server for V3 protocol
 
44
 * operations that support large requests/replies, e.g. reads and writes.
 
45
 */
 
46
#define HGFS_LARGE_IO_MAX_PAGES  15
42
47
 
43
48
/*
44
49
 * Maximum allowed packet size in bytes. All hgfs code should be made
46
51
 */
47
52
#define HGFS_PACKET_MAX 6144
48
53
 
 
54
/*
 
55
 * The HGFS_LARGE_PACKET_MAX size is used to allow guests to make
 
56
 * read / write requests of sizes larger than HGFS_PACKET_MAX. The larger size
 
57
 * can only be used with server operations that are specified to be large packet
 
58
 * capable in hgfsProto.h.
 
59
 */
 
60
#define HGFS_LARGE_PACKET_MAX ((4096 * HGFS_LARGE_IO_MAX_PAGES) + 2048)
 
61
 
 
62
/* Maximum number of bytes to read or write to a hgfs server in a single packet. */
 
63
#define HGFS_IO_MAX 4096
 
64
 
 
65
/* Maximum number of bytes to read or write to a V3 server in a single hgfs packet. */
 
66
#define HGFS_LARGE_IO_MAX (HGFS_LARGE_IO_MAX_PAGES * 4096)
49
67
 
50
68
/*
51
69
 * Open mode
113
131
 * error codes travelled from hgfsProto.h to hgfs.h in that same change. Worse,
114
132
 * we GA'ed a product (Server 1.0) this way.
115
133
 *
116
 
 * XXX: I've reversed the order because otherwise new HGFS clients working 
117
 
 * against WS55-era HGFS servers will think they got HGFS_STATUS_GENERIC_ERROR 
 
134
 * XXX: I've reversed the order because otherwise new HGFS clients working
 
135
 * against WS55-era HGFS servers will think they got HGFS_STATUS_GENERIC_ERROR
118
136
 * when the server sent them HGFS_STATUS_INVALID_NAME. This was a problem
119
137
 * the Linux client converts HGFS_STATUS_GENERIC_ERROR to -EIO, which causes
120
138
 * HgfsLookup to fail unexpectedly (normally HGFS_STATUS_INVALID_NAME is
136
154
   HGFS_STATUS_NO_SPACE,
137
155
   HGFS_STATUS_OPERATION_NOT_SUPPORTED,
138
156
   HGFS_STATUS_NAME_TOO_LONG,
 
157
   HGFS_STATUS_INVALID_PARAMETER,
139
158
} HgfsStatus;
140
159
 
141
160
/*
150
169
 * the command and the space into some buffer that is then sent over the
151
170
 * backdoor.
152
171
 *
153
 
 * In Host --> Guest RPC traffic, the host endpoint is TCLO and the guest 
154
 
 * endpoint is RpcIn. TCLO is a particularly confusing name choice which dates 
155
 
 * back to when the host was to send raw TCL code to the guest (TCL Out == 
 
172
 * In Host --> Guest RPC traffic, the host endpoint is TCLO and the guest
 
173
 * endpoint is RpcIn. TCLO is a particularly confusing name choice which dates
 
174
 * back to when the host was to send raw TCL code to the guest (TCL Out ==
156
175
 * TCLO).
157
176
 *
158
177
 * In Guest --> Host RPC traffic, the guest endpoint is RpcOut and the host
161
180
 
162
181
/*
163
182
 * When an RPCI listener registers for this command, HGFS requests are expected
164
 
 * to be synchronously sent from the guest and replies are expected to be 
 
183
 * to be synchronously sent from the guest and replies are expected to be
165
184
 * synchronously returned.
166
 
 * 
167
 
 * When an RpcIn listener registers for this command, requests are expected to 
168
 
 * be asynchronously sent from the host and synchronously returned from the 
 
185
 *
 
186
 * When an RpcIn listener registers for this command, requests are expected to
 
187
 * be asynchronously sent from the host and synchronously returned from the
169
188
 * guest.
170
189
 *
171
190
 * In short, an endpoint sending this command is sending a request whose reply
175
194
#define HGFS_SYNC_REQREP_CLIENT_CMD HGFS_SYNC_REQREP_CMD " "
176
195
#define HGFS_SYNC_REQREP_CLIENT_CMD_LEN (sizeof HGFS_SYNC_REQREP_CLIENT_CMD - 1)
177
196
 
178
 
/* 
 
197
/*
179
198
 * This is just for the sake of macro naming. Since we are guaranteed
180
199
 * equal command lengths, defining command length via a generalized macro name
181
200
 * will prevent confusion.