Hi, On Thu, Sep 6, 2012 at 2:28 PM, Jiri Svoboda <[email protected]> wrote: > 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.
There would be no direct indication if such a pointer is valid (other than knowing whether the function/device is till alive). If the framework should ease driver programming than I consider it a better place to implement this tracking rather than in every driver. > >> 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. It was not my intention so prove that there is a case in which implanting data is the only way. Merely that there are cases when it might be beneficial. Why would I use list_t for function nodes? Number of functions is known (for most devices) if not at compile time than at initialization time. IMO there is no reason to use linked lists for that (in this case it's in every aspect worse DS than array). I didn't say entire soft-state has to be shared. In your NIC example I don't see a reason why part of the device soft-state can't be used as a function soft-state (it would even support multiport cards). Another reason to share soft-states is that the framework only allows exposed functions to register in categories. Use case: device with inner functions that needs dummy node in order to register in category (like all usb devices and their ctl nodes). I think most of my arguments tread on the topic you wanted to avoid. > >> I think that allowing implant_data (or equivalent) for general use >> would be beneficial. > Sorry, you didn't convince me. It was not my intention to convince you (I know better than to battle personal preferences). I just ask you not to block the way, I consider superior, that you might not prefer or like. Jan > > Cheers > -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
