Hi Christophe, Another issue may relate to driver interface. As you know, there is some soc level initialization specific to some platform before the network driver works.
Where do you expect this kind of initialization? at the odp_init or driver_init? For dpaa2, the thread is also needed before the driver is working. thanks, Forrest On 6 February 2017 at 20:35, Christophe Milard <christophe.mil...@linaro.org > wrote: > Hi, > > I am trying to implement to API we agreed on, and I am facing a small > issue which is preceeding larger problems, I am afraid: > The small issue is: > We defined: > odpdrv_enumr_t odpdrv_enumr_register(odpdrv_enumr_param_t *param); > to register a enumerator and : > odpdrv_device_t odpdrv_device_create(odpdrv_device_param_t *param); > to register a device where param has to contains the enumerator > enumerating the device (odpdrv_enumr_t). > Seen for the enumerator, this means that the registration of the > enumerator must have returned before the enumerator probe() function > can be called. How can we guarantee this.... > My simple approach in > https://git.linaro.org/people/christophe.milard/odp.git/log/ > ?h=drv_enumerator_registration_v0.3 > was to call probe at registration time, which does not work... > One solution could be to pass the odp_enumr_t at probe time. Do we > want to do that? > The larger problem: I am not sure we will be able to make "single > threaded" drivers at all times: I feels probable that at some point, > some driver will want to create another ODP thread (for supervision of > link status for instance). > But it is said that ODP thread creation is not part of ODP, but > remains an OS stuff (we just have shortcuts in helpers). If a driver > need to create an ODP thread, and the driver should remain OS > independent, aren't we stuck? > > Christophe. >
