Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 1 | /* |
| 2 | * This file define the new driver API for Wireless Extensions |
| 3 | * |
| 4 | * Version : 6 21.6.04 |
| 5 | * |
| 6 | * Authors : Jean Tourrilhes - HPL - <jt@hpl.hp.com> |
| 7 | * Copyright (c) 2001-2004 Jean Tourrilhes, All Rights Reserved. |
| 8 | */ |
| 9 | |
| 10 | #ifndef _IW_HANDLER_H |
| 11 | #define _IW_HANDLER_H |
| 12 | |
| 13 | /************************** DOCUMENTATION **************************/ |
| 14 | /* |
| 15 | * Initial driver API (1996 -> onward) : |
| 16 | * ----------------------------------- |
| 17 | * The initial API just sends the IOCTL request received from user space |
| 18 | * to the driver (via the driver ioctl handler). The driver has to |
| 19 | * handle all the rest... |
| 20 | * |
| 21 | * The initial API also defines a specific handler in struct net_device |
| 22 | * to handle wireless statistics. |
| 23 | * |
| 24 | * The initial APIs served us well and has proven a reasonably good design. |
| 25 | * However, there is a few shortcommings : |
| 26 | * o No events, everything is a request to the driver. |
| 27 | * o Large ioctl function in driver with gigantic switch statement |
| 28 | * (i.e. spaghetti code). |
| 29 | * o Driver has to mess up with copy_to/from_user, and in many cases |
| 30 | * does it unproperly. Common mistakes are : |
| 31 | * * buffer overflows (no checks or off by one checks) |
| 32 | * * call copy_to/from_user with irq disabled |
| 33 | * o The user space interface is tied to ioctl because of the use |
| 34 | * copy_to/from_user. |
| 35 | * |
| 36 | * New driver API (2002 -> onward) : |
| 37 | * ------------------------------- |
| 38 | * The new driver API is just a bunch of standard functions (handlers), |
| 39 | * each handling a specific Wireless Extension. The driver just export |
| 40 | * the list of handler it supports, and those will be called apropriately. |
| 41 | * |
| 42 | * I tried to keep the main advantage of the previous API (simplicity, |
| 43 | * efficiency and light weight), and also I provide a good dose of backward |
| 44 | * compatibility (most structures are the same, driver can use both API |
| 45 | * simultaneously, ...). |
| 46 | * Hopefully, I've also addressed the shortcomming of the initial API. |
| 47 | * |
| 48 | * The advantage of the new API are : |
| 49 | * o Handling of Extensions in driver broken in small contained functions |
| 50 | * o Tighter checks of ioctl before calling the driver |
| 51 | * o Flexible commit strategy (at least, the start of it) |
| 52 | * o Backward compatibility (can be mixed with old API) |
| 53 | * o Driver doesn't have to worry about memory and user-space issues |
| 54 | * The last point is important for the following reasons : |
| 55 | * o You are now able to call the new driver API from any API you |
| 56 | * want (including from within other parts of the kernel). |
| 57 | * o Common mistakes are avoided (buffer overflow, user space copy |
| 58 | * with irq disabled and so on). |
| 59 | * |
| 60 | * The Drawback of the new API are : |
| 61 | * o bloat (especially kernel) |
| 62 | * o need to migrate existing drivers to new API |
| 63 | * My initial testing shows that the new API adds around 3kB to the kernel |
| 64 | * and save between 0 and 5kB from a typical driver. |
| 65 | * Also, as all structures and data types are unchanged, the migration is |
| 66 | * quite straightforward (but tedious). |
| 67 | * |
| 68 | * --- |
| 69 | * |
| 70 | * The new driver API is defined below in this file. User space should |
| 71 | * not be aware of what's happening down there... |
| 72 | * |
| 73 | * A new kernel wrapper is in charge of validating the IOCTLs and calling |
| 74 | * the appropriate driver handler. This is implemented in : |
| 75 | * # net/core/wireless.c |
| 76 | * |
| 77 | * The driver export the list of handlers in : |
| 78 | * # include/linux/netdevice.h (one place) |
| 79 | * |
| 80 | * The new driver API is available for WIRELESS_EXT >= 13. |
| 81 | * Good luck with migration to the new API ;-) |
| 82 | */ |
| 83 | |
| 84 | /* ---------------------- THE IMPLEMENTATION ---------------------- */ |
| 85 | /* |
| 86 | * Some of the choice I've made are pretty controversials. Defining an |
| 87 | * API is very much weighting compromises. This goes into some of the |
| 88 | * details and the thinking behind the implementation. |
| 89 | * |
| 90 | * Implementation goals : |
| 91 | * -------------------- |
| 92 | * The implementation goals were as follow : |
| 93 | * o Obvious : you should not need a PhD to understand what's happening, |
| 94 | * the benefit is easier maintainance. |
| 95 | * o Flexible : it should accommodate a wide variety of driver |
| 96 | * implementations and be as flexible as the old API. |
| 97 | * o Lean : it should be efficient memory wise to minimise the impact |
| 98 | * on kernel footprint. |
| 99 | * o Transparent to user space : the large number of user space |
| 100 | * applications that use Wireless Extensions should not need |
| 101 | * any modifications. |
| 102 | * |
| 103 | * Array of functions versus Struct of functions |
| 104 | * --------------------------------------------- |
| 105 | * 1) Having an array of functions allow the kernel code to access the |
| 106 | * handler in a single lookup, which is much more efficient (think hash |
| 107 | * table here). |
| 108 | * 2) The only drawback is that driver writer may put their handler in |
| 109 | * the wrong slot. This is trivial to test (I set the frequency, the |
| 110 | * bitrate changes). Once the handler is in the proper slot, it will be |
| 111 | * there forever, because the array is only extended at the end. |
| 112 | * 3) Backward/forward compatibility : adding new handler just require |
| 113 | * extending the array, so you can put newer driver in older kernel |
| 114 | * without having to patch the kernel code (and vice versa). |
| 115 | * |
| 116 | * All handler are of the same generic type |
| 117 | * ---------------------------------------- |
| 118 | * That's a feature !!! |
| 119 | * 1) Having a generic handler allow to have generic code, which is more |
| 120 | * efficient. If each of the handler was individually typed I would need |
| 121 | * to add a big switch in the kernel (== more bloat). This solution is |
| 122 | * more scalable, adding new Wireless Extensions doesn't add new code. |
| 123 | * 2) You can use the same handler in different slots of the array. For |
| 124 | * hardware, it may be more efficient or logical to handle multiple |
| 125 | * Wireless Extensions with a single function, and the API allow you to |
| 126 | * do that. (An example would be a single record on the card to control |
| 127 | * both bitrate and frequency, the handler would read the old record, |
| 128 | * modify it according to info->cmd and rewrite it). |
| 129 | * |
| 130 | * Functions prototype uses union iwreq_data |
| 131 | * ----------------------------------------- |
| 132 | * Some would have prefered functions defined this way : |
| 133 | * static int mydriver_ioctl_setrate(struct net_device *dev, |
| 134 | * long rate, int auto) |
| 135 | * 1) The kernel code doesn't "validate" the content of iwreq_data, and |
| 136 | * can't do it (different hardware may have different notion of what a |
| 137 | * valid frequency is), so we don't pretend that we do it. |
| 138 | * 2) The above form is not extendable. If I want to add a flag (for |
| 139 | * example to distinguish setting max rate and basic rate), I would |
| 140 | * break the prototype. Using iwreq_data is more flexible. |
| 141 | * 3) Also, the above form is not generic (see above). |
| 142 | * 4) I don't expect driver developper using the wrong field of the |
| 143 | * union (Doh !), so static typechecking doesn't add much value. |
| 144 | * 5) Lastly, you can skip the union by doing : |
| 145 | * static int mydriver_ioctl_setrate(struct net_device *dev, |
| 146 | * struct iw_request_info *info, |
| 147 | * struct iw_param *rrq, |
| 148 | * char *extra) |
| 149 | * And then adding the handler in the array like this : |
| 150 | * (iw_handler) mydriver_ioctl_setrate, // SIOCSIWRATE |
| 151 | * |
| 152 | * Using functions and not a registry |
| 153 | * ---------------------------------- |
| 154 | * Another implementation option would have been for every instance to |
| 155 | * define a registry (a struct containing all the Wireless Extensions) |
| 156 | * and only have a function to commit the registry to the hardware. |
| 157 | * 1) This approach can be emulated by the current code, but not |
| 158 | * vice versa. |
| 159 | * 2) Some drivers don't keep any configuration in the driver, for them |
| 160 | * adding such a registry would be a significant bloat. |
| 161 | * 3) The code to translate from Wireless Extension to native format is |
| 162 | * needed anyway, so it would not reduce significantely the amount of code. |
| 163 | * 4) The current approach only selectively translate Wireless Extensions |
| 164 | * to native format and only selectively set, whereas the registry approach |
| 165 | * would require to translate all WE and set all parameters for any single |
| 166 | * change. |
| 167 | * 5) For many Wireless Extensions, the GET operation return the current |
| 168 | * dynamic value, not the value that was set. |
| 169 | * |
| 170 | * This header is <net/iw_handler.h> |
| 171 | * --------------------------------- |
| 172 | * 1) This header is kernel space only and should not be exported to |
| 173 | * user space. Headers in "include/linux/" are exported, headers in |
| 174 | * "include/net/" are not. |
| 175 | * |
| 176 | * Mixed 32/64 bit issues |
| 177 | * ---------------------- |
| 178 | * The Wireless Extensions are designed to be 64 bit clean, by using only |
| 179 | * datatypes with explicit storage size. |
| 180 | * There are some issues related to kernel and user space using different |
| 181 | * memory model, and in particular 64bit kernel with 32bit user space. |
| 182 | * The problem is related to struct iw_point, that contains a pointer |
| 183 | * that *may* need to be translated. |
| 184 | * This is quite messy. The new API doesn't solve this problem (it can't), |
| 185 | * but is a step in the right direction : |
| 186 | * 1) Meta data about each ioctl is easily available, so we know what type |
| 187 | * of translation is needed. |
| 188 | * 2) The move of data between kernel and user space is only done in a single |
| 189 | * place in the kernel, so adding specific hooks in there is possible. |
| 190 | * 3) In the long term, it allows to move away from using ioctl as the |
| 191 | * user space API. |
| 192 | * |
| 193 | * So many comments and so few code |
| 194 | * -------------------------------- |
| 195 | * That's a feature. Comments won't bloat the resulting kernel binary. |
| 196 | */ |
| 197 | |
| 198 | /***************************** INCLUDES *****************************/ |
| 199 | |
| 200 | #include <linux/wireless.h> /* IOCTL user space API */ |
| 201 | #include <linux/if_ether.h> |
| 202 | |
| 203 | /***************************** VERSION *****************************/ |
| 204 | /* |
| 205 | * This constant is used to know which version of the driver API is |
| 206 | * available. Hopefully, this will be pretty stable and no changes |
| 207 | * will be needed... |
| 208 | * I just plan to increment with each new version. |
| 209 | */ |
| 210 | #define IW_HANDLER_VERSION 6 |
| 211 | |
| 212 | /* |
| 213 | * Changes : |
| 214 | * |
| 215 | * V2 to V3 |
| 216 | * -------- |
| 217 | * - Move event definition in <linux/wireless.h> |
| 218 | * - Add Wireless Event support : |
| 219 | * o wireless_send_event() prototype |
| 220 | * o iwe_stream_add_event/point() inline functions |
| 221 | * V3 to V4 |
| 222 | * -------- |
| 223 | * - Reshuffle IW_HEADER_TYPE_XXX to map IW_PRIV_TYPE_XXX changes |
| 224 | * |
| 225 | * V4 to V5 |
| 226 | * -------- |
| 227 | * - Add new spy support : struct iw_spy_data & prototypes |
| 228 | * |
| 229 | * V5 to V6 |
| 230 | * -------- |
| 231 | * - Change the way we get to spy_data method for added safety |
| 232 | * - Remove spy #ifdef, they are always on -> cleaner code |
| 233 | * - Add IW_DESCR_FLAG_NOMAX flag for very large requests |
| 234 | * - Start migrating get_wireless_stats to struct iw_handler_def |
| 235 | */ |
| 236 | |
| 237 | /**************************** CONSTANTS ****************************/ |
| 238 | |
| 239 | /* Enhanced spy support available */ |
| 240 | #define IW_WIRELESS_SPY |
| 241 | #define IW_WIRELESS_THRSPY |
| 242 | |
| 243 | /* Special error message for the driver to indicate that we |
| 244 | * should do a commit after return from the iw_handler */ |
| 245 | #define EIWCOMMIT EINPROGRESS |
| 246 | |
| 247 | /* Flags available in struct iw_request_info */ |
| 248 | #define IW_REQUEST_FLAG_NONE 0x0000 /* No flag so far */ |
| 249 | |
| 250 | /* Type of headers we know about (basically union iwreq_data) */ |
| 251 | #define IW_HEADER_TYPE_NULL 0 /* Not available */ |
| 252 | #define IW_HEADER_TYPE_CHAR 2 /* char [IFNAMSIZ] */ |
| 253 | #define IW_HEADER_TYPE_UINT 4 /* __u32 */ |
| 254 | #define IW_HEADER_TYPE_FREQ 5 /* struct iw_freq */ |
| 255 | #define IW_HEADER_TYPE_ADDR 6 /* struct sockaddr */ |
| 256 | #define IW_HEADER_TYPE_POINT 8 /* struct iw_point */ |
| 257 | #define IW_HEADER_TYPE_PARAM 9 /* struct iw_param */ |
| 258 | #define IW_HEADER_TYPE_QUAL 10 /* struct iw_quality */ |
| 259 | |
| 260 | /* Handling flags */ |
| 261 | /* Most are not implemented. I just use them as a reminder of some |
| 262 | * cool features we might need one day ;-) */ |
| 263 | #define IW_DESCR_FLAG_NONE 0x0000 /* Obvious */ |
| 264 | /* Wrapper level flags */ |
| 265 | #define IW_DESCR_FLAG_DUMP 0x0001 /* Not part of the dump command */ |
| 266 | #define IW_DESCR_FLAG_EVENT 0x0002 /* Generate an event on SET */ |
| 267 | #define IW_DESCR_FLAG_RESTRICT 0x0004 /* GET : request is ROOT only */ |
| 268 | /* SET : Omit payload from generated iwevent */ |
| 269 | #define IW_DESCR_FLAG_NOMAX 0x0008 /* GET : no limit on request size */ |
| 270 | /* Driver level flags */ |
| 271 | #define IW_DESCR_FLAG_WAIT 0x0100 /* Wait for driver event */ |
| 272 | |
| 273 | /****************************** TYPES ******************************/ |
| 274 | |
| 275 | /* ----------------------- WIRELESS HANDLER ----------------------- */ |
| 276 | /* |
| 277 | * A wireless handler is just a standard function, that looks like the |
| 278 | * ioctl handler. |
| 279 | * We also define there how a handler list look like... As the Wireless |
| 280 | * Extension space is quite dense, we use a simple array, which is faster |
| 281 | * (that's the perfect hash table ;-). |
| 282 | */ |
| 283 | |
| 284 | /* |
| 285 | * Meta data about the request passed to the iw_handler. |
| 286 | * Most handlers can safely ignore what's in there. |
| 287 | * The 'cmd' field might come handy if you want to use the same handler |
| 288 | * for multiple command... |
| 289 | * This struct is also my long term insurance. I can add new fields here |
| 290 | * without breaking the prototype of iw_handler... |
| 291 | */ |
| 292 | struct iw_request_info |
| 293 | { |
| 294 | __u16 cmd; /* Wireless Extension command */ |
| 295 | __u16 flags; /* More to come ;-) */ |
| 296 | }; |
| 297 | |
| 298 | struct net_device; |
| 299 | |
| 300 | /* |
| 301 | * This is how a function handling a Wireless Extension should look |
| 302 | * like (both get and set, standard and private). |
| 303 | */ |
| 304 | typedef int (*iw_handler)(struct net_device *dev, struct iw_request_info *info, |
| 305 | union iwreq_data *wrqu, char *extra); |
| 306 | |
| 307 | /* |
| 308 | * This define all the handler that the driver export. |
| 309 | * As you need only one per driver type, please use a static const |
| 310 | * shared by all driver instances... Same for the members... |
| 311 | * This will be linked from net_device in <linux/netdevice.h> |
| 312 | */ |
| 313 | struct iw_handler_def |
| 314 | { |
| 315 | /* Number of handlers defined (more precisely, index of the |
| 316 | * last defined handler + 1) */ |
| 317 | __u16 num_standard; |
| 318 | __u16 num_private; |
| 319 | /* Number of private arg description */ |
| 320 | __u16 num_private_args; |
| 321 | |
| 322 | /* Array of handlers for standard ioctls |
| 323 | * We will call dev->wireless_handlers->standard[ioctl - SIOCSIWNAME] |
| 324 | */ |
| 325 | const iw_handler * standard; |
| 326 | |
| 327 | /* Array of handlers for private ioctls |
| 328 | * Will call dev->wireless_handlers->private[ioctl - SIOCIWFIRSTPRIV] |
| 329 | */ |
| 330 | const iw_handler * private; |
| 331 | |
| 332 | /* Arguments of private handler. This one is just a list, so you |
| 333 | * can put it in any order you want and should not leave holes... |
| 334 | * We will automatically export that to user space... */ |
| 335 | const struct iw_priv_args * private_args; |
| 336 | |
| 337 | /* This field will be *removed* in the next version of WE */ |
| 338 | long spy_offset; /* DO NOT USE */ |
| 339 | |
| 340 | /* New location of get_wireless_stats, to de-bloat struct net_device. |
| 341 | * The old pointer in struct net_device will be gradually phased |
| 342 | * out, and drivers are encouraged to use this one... */ |
| 343 | struct iw_statistics* (*get_wireless_stats)(struct net_device *dev); |
| 344 | }; |
| 345 | |
| 346 | /* ---------------------- IOCTL DESCRIPTION ---------------------- */ |
| 347 | /* |
| 348 | * One of the main goal of the new interface is to deal entirely with |
| 349 | * user space/kernel space memory move. |
| 350 | * For that, we need to know : |
| 351 | * o if iwreq is a pointer or contain the full data |
| 352 | * o what is the size of the data to copy |
| 353 | * |
| 354 | * For private IOCTLs, we use the same rules as used by iwpriv and |
| 355 | * defined in struct iw_priv_args. |
| 356 | * |
| 357 | * For standard IOCTLs, things are quite different and we need to |
| 358 | * use the stuctures below. Actually, this struct is also more |
| 359 | * efficient, but that's another story... |
| 360 | */ |
| 361 | |
| 362 | /* |
| 363 | * Describe how a standard IOCTL looks like. |
| 364 | */ |
| 365 | struct iw_ioctl_description |
| 366 | { |
| 367 | __u8 header_type; /* NULL, iw_point or other */ |
| 368 | __u8 token_type; /* Future */ |
| 369 | __u16 token_size; /* Granularity of payload */ |
| 370 | __u16 min_tokens; /* Min acceptable token number */ |
| 371 | __u16 max_tokens; /* Max acceptable token number */ |
| 372 | __u32 flags; /* Special handling of the request */ |
| 373 | }; |
| 374 | |
| 375 | /* Need to think of short header translation table. Later. */ |
| 376 | |
| 377 | /* --------------------- ENHANCED SPY SUPPORT --------------------- */ |
| 378 | /* |
| 379 | * In the old days, the driver was handling spy support all by itself. |
| 380 | * Now, the driver can delegate this task to Wireless Extensions. |
| 381 | * It needs to include this struct in its private part and use the |
| 382 | * standard spy iw_handler. |
| 383 | */ |
| 384 | |
| 385 | /* |
| 386 | * Instance specific spy data, i.e. addresses spied and quality for them. |
| 387 | */ |
| 388 | struct iw_spy_data |
| 389 | { |
| 390 | /* --- Standard spy support --- */ |
| 391 | int spy_number; |
| 392 | u_char spy_address[IW_MAX_SPY][ETH_ALEN]; |
| 393 | struct iw_quality spy_stat[IW_MAX_SPY]; |
| 394 | /* --- Enhanced spy support (event) */ |
| 395 | struct iw_quality spy_thr_low; /* Low threshold */ |
| 396 | struct iw_quality spy_thr_high; /* High threshold */ |
| 397 | u_char spy_thr_under[IW_MAX_SPY]; |
| 398 | }; |
| 399 | |
| 400 | /* --------------------- DEVICE WIRELESS DATA --------------------- */ |
| 401 | /* |
| 402 | * This is all the wireless data specific to a device instance that |
| 403 | * is managed by the core of Wireless Extensions. |
| 404 | * We only keep pointer to those structures, so that a driver is free |
| 405 | * to share them between instances. |
| 406 | * This structure should be initialised before registering the device. |
| 407 | * Access to this data follow the same rules as any other struct net_device |
| 408 | * data (i.e. valid as long as struct net_device exist, same locking rules). |
| 409 | */ |
| 410 | struct iw_public_data { |
| 411 | /* Driver enhanced spy support */ |
| 412 | struct iw_spy_data * spy_data; |
| 413 | }; |
| 414 | |
| 415 | /**************************** PROTOTYPES ****************************/ |
| 416 | /* |
| 417 | * Functions part of the Wireless Extensions (defined in net/core/wireless.c). |
| 418 | * Those may be called only within the kernel. |
| 419 | */ |
| 420 | |
| 421 | /* First : function strictly used inside the kernel */ |
| 422 | |
| 423 | /* Handle /proc/net/wireless, called in net/code/dev.c */ |
| 424 | extern int dev_get_wireless_info(char * buffer, char **start, off_t offset, |
| 425 | int length); |
| 426 | |
| 427 | /* Handle IOCTLs, called in net/code/dev.c */ |
| 428 | extern int wireless_process_ioctl(struct ifreq *ifr, unsigned int cmd); |
| 429 | |
| 430 | /* Second : functions that may be called by driver modules */ |
| 431 | |
| 432 | /* Send a single event to user space */ |
| 433 | extern void wireless_send_event(struct net_device * dev, |
| 434 | unsigned int cmd, |
| 435 | union iwreq_data * wrqu, |
| 436 | char * extra); |
| 437 | |
| 438 | /* We may need a function to send a stream of events to user space. |
| 439 | * More on that later... */ |
| 440 | |
| 441 | /* Standard handler for SIOCSIWSPY */ |
| 442 | extern int iw_handler_set_spy(struct net_device * dev, |
| 443 | struct iw_request_info * info, |
| 444 | union iwreq_data * wrqu, |
| 445 | char * extra); |
| 446 | /* Standard handler for SIOCGIWSPY */ |
| 447 | extern int iw_handler_get_spy(struct net_device * dev, |
| 448 | struct iw_request_info * info, |
| 449 | union iwreq_data * wrqu, |
| 450 | char * extra); |
| 451 | /* Standard handler for SIOCSIWTHRSPY */ |
| 452 | extern int iw_handler_set_thrspy(struct net_device * dev, |
| 453 | struct iw_request_info *info, |
| 454 | union iwreq_data * wrqu, |
| 455 | char * extra); |
| 456 | /* Standard handler for SIOCGIWTHRSPY */ |
| 457 | extern int iw_handler_get_thrspy(struct net_device * dev, |
| 458 | struct iw_request_info *info, |
| 459 | union iwreq_data * wrqu, |
| 460 | char * extra); |
| 461 | /* Driver call to update spy records */ |
| 462 | extern void wireless_spy_update(struct net_device * dev, |
| 463 | unsigned char * address, |
| 464 | struct iw_quality * wstats); |
| 465 | |
| 466 | /************************* INLINE FUNTIONS *************************/ |
| 467 | /* |
| 468 | * Function that are so simple that it's more efficient inlining them |
| 469 | */ |
| 470 | |
| 471 | /*------------------------------------------------------------------*/ |
| 472 | /* |
| 473 | * Wrapper to add an Wireless Event to a stream of events. |
| 474 | */ |
| 475 | static inline char * |
| 476 | iwe_stream_add_event(char * stream, /* Stream of events */ |
| 477 | char * ends, /* End of stream */ |
| 478 | struct iw_event *iwe, /* Payload */ |
| 479 | int event_len) /* Real size of payload */ |
| 480 | { |
| 481 | /* Check if it's possible */ |
| 482 | if((stream + event_len) < ends) { |
| 483 | iwe->len = event_len; |
| 484 | memcpy(stream, (char *) iwe, event_len); |
| 485 | stream += event_len; |
| 486 | } |
| 487 | return stream; |
| 488 | } |
| 489 | |
| 490 | /*------------------------------------------------------------------*/ |
| 491 | /* |
| 492 | * Wrapper to add an short Wireless Event containing a pointer to a |
| 493 | * stream of events. |
| 494 | */ |
| 495 | static inline char * |
| 496 | iwe_stream_add_point(char * stream, /* Stream of events */ |
| 497 | char * ends, /* End of stream */ |
| 498 | struct iw_event *iwe, /* Payload */ |
| 499 | char * extra) |
| 500 | { |
| 501 | int event_len = IW_EV_POINT_LEN + iwe->u.data.length; |
| 502 | /* Check if it's possible */ |
| 503 | if((stream + event_len) < ends) { |
| 504 | iwe->len = event_len; |
| 505 | memcpy(stream, (char *) iwe, IW_EV_POINT_LEN); |
| 506 | memcpy(stream + IW_EV_POINT_LEN, extra, iwe->u.data.length); |
| 507 | stream += event_len; |
| 508 | } |
| 509 | return stream; |
| 510 | } |
| 511 | |
| 512 | /*------------------------------------------------------------------*/ |
| 513 | /* |
| 514 | * Wrapper to add a value to a Wireless Event in a stream of events. |
| 515 | * Be careful, this one is tricky to use properly : |
| 516 | * At the first run, you need to have (value = event + IW_EV_LCP_LEN). |
| 517 | */ |
| 518 | static inline char * |
| 519 | iwe_stream_add_value(char * event, /* Event in the stream */ |
| 520 | char * value, /* Value in event */ |
| 521 | char * ends, /* End of stream */ |
| 522 | struct iw_event *iwe, /* Payload */ |
| 523 | int event_len) /* Real size of payload */ |
| 524 | { |
| 525 | /* Don't duplicate LCP */ |
| 526 | event_len -= IW_EV_LCP_LEN; |
| 527 | |
| 528 | /* Check if it's possible */ |
| 529 | if((value + event_len) < ends) { |
| 530 | /* Add new value */ |
| 531 | memcpy(value, (char *) iwe + IW_EV_LCP_LEN, event_len); |
| 532 | value += event_len; |
| 533 | /* Patch LCP */ |
| 534 | iwe->len = value - event; |
| 535 | memcpy(event, (char *) iwe, IW_EV_LCP_LEN); |
| 536 | } |
| 537 | return value; |
| 538 | } |
| 539 | |
| 540 | #endif /* _IW_HANDLER_H */ |