Changes between Version 18 and Version 19 of DeviceDrivers
- Timestamp:
- 2011-11-14T21:27:27Z (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
DeviceDrivers
v18 v19 167 167 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). 168 168 169 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. 'ddf_dev_data_alloc'' is normally called from within the '' add_device'' emtry point.169 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. 'ddf_dev_data_alloc'' is normally called from within the ''dev_add'' emtry point. 170 170 171 171 In practice, as long as you don't copy the pointer to device or function soft-state to a global/heap structure or pass it to another thread, it can never become dangling. As long as you have the reference, it is valid (i.e. points to an allocated block). ''ddf_fun_data_alloc'' is called on an unbound function (after creating, before binding).