* Andrzej Pietrasiewicz | 2013-01-15 16:26:20 [+0100]: >On Tuesday, January 15, 2013 1:03 PM Sebastian Andrzej Siewior wrote: > ><snip> > >> >usb_function_driver. >> > >> >I would call the structure in question "usb_function_module". >> >Or even better: "usb_function_pool" - you get usb_functions from it. >> >Please see inline for what it looks like. >> >> Not sure I can agree here. It is not what we use "usb_function" for. >> That thing that comes out of "try_get_usb_function_instance", the >> usb_function_instance, is an instance which matches what I read here [0]. >> Yes, it is a specific USB function, with the same "configuration". > >So it looks like the "usb_function_instance" is in fact a usb function's >_configuration_ instance? It is a specific function with specific configuration set. Some of them are static like the device name for ttyACM and some may be changed like, lets say, the mac address of the NCM gadget. >> "usb_function" is something we use in "usb_configuration" and those two >> are not the same. > >Yet, the first thing that comes to my mind after I think of a "usb function >instance" (no underscores here intentionally) is an instance >of a struct usb_function. This is confusing me. It took me a long while >until I understood what is going on here. Would you mind finding a >better name for it? I agree. First I had usb_function and complained later that it does not compile :) Then I had something else what Felipe did not like at all and now I have this. > >In order not to confuse those two I just picked >> something else. try_get_usb_function_instance() returnes severel kinds of >> objects so it does not match "pool" in OO language. If you look at >> skb_pool you expect a skb and always a skb and each skb has the same >> capabilities. This is simple not true here. >> I think in OO language try_get_usb_function_instance() would match a >> "fabric" and usb_get_function() would match the "pool". >> > >I meant to call the _struct_ usb_function_instance a usb_function_pool. >This in fact is consistent with what you say above: in OO language >you could call a factory method on behalf of some object (or perhaps, >a class). In C we pass this object explicitly as there is no "this" >pointer. So to the usb_get_function() factory method is called on >behalf of some object which is passed as an argument. And I suggest >calling this argument a usb_function_pool: > >/* pool below is the "this" */ >struct usb_function *usb_get_function(struct usb_function_pool *pool); > >so the "usb_get_function" method is called on behalf of some pool. > >I am not insisting on "pool". But for the reasons given above I >would like the struct usb_function_instance (and its dependent >names) to be called differently. Hmmm. I think I can live with this. Unless Felipe vetoes I don't mind if you send a rename path. >AP Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
