Hi, On 12/06/2016 05:40 AM, fx IWATA NOBUO wrote: > Hello, > >>> usbip_driver_<something> has widely used as function names and file >>> names for host side abstraction. >>> If they were usbip_host_<something>, I can use usbip_driver_open/close >>> for both host(stub/vudc) and vhci. >> >> usbip_host<sth>() is not correct name to use for both stub and vudc as from >> USB point of view stub is on a host but vudc is on a device side > > OK. > >> maybe a kind of usbipd_backed_init() would be more suitable? > > Naming problem again but I recognize usbip_open_driver() is worse than > connect. > I think the word 'backend' has wide meaning and more strict word is > better. > > init driver = &host_driver; NA > ( ) driver = &device_driver; NA > open usbip_driver_open usbip_vhci_driver_open > close usbip_driver_close usbip_vhci_driver_close > > Here, I'd like to use word 'driver'. > I searched analogy meta_, super_ in kernel. > > How about usbip_meta_driver_init/open/close()? Sounds good. Let's try. > >>>> usbip_update_driver() is t totally unrelated to what this assignment >>>> really does. >> So as above. I suggest to call it usbipd_backend() instead of driver. > > Please, let me know good verb representing 'driver = &device_driver'. how about usbip_meta_driver_set(type)? Best regards, -- Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics -- 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
