76 | | * ddf_dev_data_alloc() |
77 | | * ddf_fun_data_alloc() |
| 76 | A driver can associate driver-specific data with its devices, functions or both. The framework provides a way to allocate a block of memory (soft state) associated with a device or function and allows the driver to obtain pointer to this memory block. The framework frees the soft state automatically (and in such a way that it does not happen while the driver is still accessing it). |
| 77 | |
| 78 | The driver is expected to synchronize access to this soft-state structure on its own in order to achieve mutual exclusion. Since the framework ensures that soft-state is not deallocated while the driver is accessing it, the synchronization can be as simple as a mutex embedded in the structure. |
| 79 | |
| 80 | The soft-state management functions are: |
| 81 | * void *ddf_dev_data_alloc(ddf_dev_t *dev, size_t size) - allocate driver-specific device data |
| 82 | * void *ddf_fun_data_alloc(ddf_fun_t *fun, size_t size) - allocate driver-specific function data |
| 83 | |
| 84 | The function ''ddf_dev_data_alloc'' allocates a driver-specific data strutcure ''size'' bytes large, associated with the device ''dev''. The structure will not be deallocated by the framework until the ''dev_remove'' or ''dev_gone'' entry point returns '''and''' control exits all driver entry points that are invoked with ''dev'' as a parameter. (Internally, this is achieved using reference counting). |
| 85 | |
| 86 | The function ''ddf_fun_data_alloc'' allocates a driver-specific data structure ''size'' bytes large, associated with the function ''fun''. The structure will not be deallocated by the framework until ''ddf_fun_destroy()'' is called '''and''' control exits all driver entry points that are invoked with ''fun'' as parameter. |
| 87 | |
| 88 | In practice, as long as you don't copy the pointer to device or function soft-state to a global structure, it can never become dangling. As long as you have the reference, it is valid (i.e. points to an allocated block). |