* Andrzej Pietrasiewicz | 2013-01-03 16:37:45 [+0100]: >Hello Sebastian, Hello Andrzej, >On Sunday, December 23, 2012 9:10 PM Sebastian Andrzej Siewior wrote: > >> Subject: [PATCH 06/30] usb/gadget: add some infracture to >> register/unregister functions >> >> This patch provides an infrastructure to register & unregister a USB >> function. This allows to turn a function into a module and avoid the >> '#include "f_.*.c"' magic and we get a clear API / cut between the bare >> gadget and its functions. >> The concept is simple: >> Each function defines the DECLARE_USB_FUNCTION_INIT macro whith an unique >> name of the function and two allocation functions. >> - one to create an "instance". The instance holds the current >> configuration >> set. In case there are two usb_configudations with one function there >> will >> be one instance and two usb_functions >> - one to create an "function" from the instance. >> > >This naming scheme seems confusing when compared with the >object-oriented (OO) parlance. In OO there is a class which >can be instantiated in many instances. It is exactly the opposite >here: there is one instance for which many functions can be created. > >The idea of having this "instance" struct is not bad itself. >As far as I understand it there are usb_function_drivers, which are >used to keep the information about currently loaded modules which >implement usb functions. Then there are "usb_function_instances", >which are used to actually cause a module implementing a usb function >to load, e.g. so that configfs has something to operate on before >usb_functions are created. And then there are usb_functions >which do the usb stuff proper and can be created in many instances per >each 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". "usb_function" is something we use in "usb_configuration" and those two are not the same. 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". [0] http://en.wikipedia.org/wiki/Instance_%28computer_science%29 >> +#define DECLARE_USB_FUNCTION(_name, _inst_alloc, _func_alloc) \ >> + static struct usb_function_driver _name ## usb_func = { \ >> + .name = __stringify(_name), \ >> + .mod = THIS_MODULE, \ >> + .alloc_inst = _inst_alloc, \ >> + .alloc_func = _func_alloc, \ >> + }; \ >> + MODULE_ALIAS("usbfunc:"__stringify(_name)); >> + >> +#define DECLARE_USB_FUNCTION_INIT(_name, _inst_alloc, _func_alloc) \ >> + DECLARE_USB_FUNCTION(_name, _inst_alloc, _func_alloc) \ >> + static int __init _name ## mod_init(void) \ >> + { \ >> + return usb_function_register(&_name ## usb_func); \ >> + } \ >> + static void __exit _name ## mod_exit(void) \ >> + { \ >> + usb_function_unregister(&_name ## usb_func); \ >> + } \ >> + module_init(_name ## mod_init); \ >> + module_exit(_name ## mod_exit) >> + > >I don't understand splitting the macro in two. The latter macro is >to be used in modules and this is what you recommend, and it calls >the first macro. So the first macro should be used in places other >than modules, but the very reason of this patch is to make f_xxxx.c >files modules. Code clarity improvements because of this are >disputable; I find this split rather confusing. >Can you give an example situation where the first macro >must be called without the second macro? Since you found it, I skip this :) 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
