Hi On Wed, Sep 5, 2012 at 8:42 AM, Jiri Svoboda <[email protected]> wrote: > HI Jano, > > Ján Veselý wrote: >> after the recent changes to ddf_dev and ddf_fun I found this code in >> driver.h header: >> >> /** XXX Only to transition USB */ >> #ifdef _DDF_DATA_IMPLANT >> extern void ddf_fun_data_implant(ddf_fun_t *, void *); >> #endif >> >> Does it mean that in the future only heap allocated function data will >> be supported? > DDF tries to make the life of a driver simpler by managing the lifetime of > the device and function soft state (driver-specific data structure). DDF > counts references to the device/function and frees the device/function node > and the associated driver-specific data structure when the reference count > drops to zero. > > This means the driver only needs to put a simple mutex into the soft state > structure for synchronization, possibly a boolean to mark the device as torn > down, and it's ready to go. (Otherwise the driver would probably have to do > some reference counting itself). > > Since the framework frees the memory, you also call the framework to allocate > it - always from the heap. > >> I hope not. > Why not? Is there any particular case where this is a problem?
maybe I put it wrong. I'm not against the framework doing all these things, but I'd appreciate if providing own pointers would remain a possibility. Function soft-states can be just parts of a device soft-state (with or without interactions between them) or the same softstate can be shared between functions (or a function and a device). In these use cases I prefer to supply functions with pointers to existing structures instead of letting them allocate their own, thus the structures' availability is not controlled by the framework. In general I prefer embedded structures to use of pointers and heap allocations (this might be a topic for broader discussion). I think that allowing implant_data (or equivalent) for general use would be beneficial. jan vesely > > Regards, > Jiri > > _______________________________________________ > HelenOS-devel mailing list > [email protected] > http://lists.modry.cz/cgi-bin/listinfo/helenos-devel _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
