Hi, > 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). It could be implemented, the framework would have to track who the owner of the structure is (and thus who is supposed to free it). It would be purely a convenience measure. You can do the same with very little overhead, simply declare a structure for the soft state with a single member - pointer to the shared structure.
> 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. I sincerely doubt there is such a use case. Even the most trivial/example driver needs to track both per-device and per-function state if it supports device removal (and all drivers should support it). For device data we need a list_t of functions and for function data we need link_t and client count. I know some of the current frameworks use the same soft state structure for device and function - for example NIC framework. This is a bug and as a consequence it cannot support multiport network adapters (single device providing multiple network interfaces). Also the performance/memory penalty incurred by allocating a separate heap block for each device/function is perfectly acceptable. > In general I prefer > embedded structures to use of pointers and heap allocations (this > might be a topic for broader discussion). Indeed. Therefore I shall carefully avoid the topic. > I think that allowing implant_data (or equivalent) for general use > would be beneficial. Sorry, you didn't convince me. Cheers -Jiri _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
