| Message ID | 1477940323-7278-2-git-send-email-christophe.milard@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
On 10/31 19:58:39, Christophe Milard wrote: > The driver registration function (and a draft of its parameters) is > defined, the goal being to define the driver registration framework only. > > Signed-off-by: Christophe Milard <christophe.milard@linaro.org> > --- > include/odp/drv/spec/driver.h | 76 +++++++++++++++++++++++++++++++++++++++++++ > platform/Makefile.inc | 1 + > 2 files changed, 77 insertions(+) > create mode 100644 include/odp/drv/spec/driver.h > > diff --git a/include/odp/drv/spec/driver.h b/include/odp/drv/spec/driver.h > new file mode 100644 > index 0000000..467201a > --- /dev/null > +++ b/include/odp/drv/spec/driver.h > @@ -0,0 +1,76 @@ > +/* Copyright (c) 2016, Linaro Limited > + * All rights reserved. > + * > + * SPDX-License-Identifier: BSD-3-Clause > + */ > + > +/** > + * @file > + * > + * ODPDRV driver > + */ > + > +#ifndef ODPDRV_DRIVER_H_ > +#define ODPDRV_DRIVER_H_ > +#include <odp/visibility_begin.h> > + > +#ifdef __cplusplus > +extern "C" { > +#endif > + > +/** > + * @addtogroup odpdrv_driver > + * @details > + * NIC driver interface to ODP Is 'NIC driver interface' just a pktio (pktio_if_ops_t) or is there more? There is a packet copy in mbuf_to_pkt(), does this driver layer involve memory? 'odpdrv_driver' sounds like the top-most driver for the whole board or an entire ODP implementation. Would there be other layers in this driver? > + * @{ > + */ > + > +/** > + * Different busses drivers can handle: > + */ > +typedef enum odpdrv_bus_t { > + UNKNOWN_BUS, /**< error case: no driver should use that */ > + PCI /**< pci bus, for all kind of pci drivers */ > +} odpdrv_bus_t; > > +/** > + * Different driver types > + */ > +typedef enum odpdrv_driver_types_t { > + UNKNOWN_TYPE, /**< error case: no driver should use that */ > + PCI_VIRTIO, /**< pci virtio driver */ > + PCI_VFIO /**< pci_vfio: vfio interface required */ Should 'PCI' be a suffix instead of a prefix? Could a VFIO-based driver issue R or W transactions that go over a bus other than PCI like MDIO or maybe no bus at all? > +} odpdrv_driver_types_t; > + > +/** > + * Parameter to be given at driver registration: > + */ > +typedef struct odpdrv_driver_param_t { > + const char *name; /**< Driver name. */ > + odpdrv_bus_t bus; /**< Driver type. */ > + odpdrv_driver_types_t type; /**< Driver type. */ > +} odpdrv_driver_param_t; > + > +/** > + * Register a Driver. > + * A call to this function should be made by all drivers at init time. > + * (called by an init function in the driver, probably using gcc/clang > + * __constructor__ attribute. > + * > + * @param drv_param Pointer to a driver registration structure. > + * @return 0 on success, non-zero on error. On error, drivers > + * should release allocated resources and return. > + */ > +int odpdrv_driver_register(odpdrv_driver_param_t *drv_param); > + > +/** > + * @} > + */ > + > +#ifdef __cplusplus > +} > +#endif > + > +#include <odp/visibility_end.h> > +#endif > diff --git a/platform/Makefile.inc b/platform/Makefile.inc > index b31b95b..69ee878 100644 > --- a/platform/Makefile.inc > +++ b/platform/Makefile.inc > @@ -67,6 +67,7 @@ odpdrvspecinclude_HEADERS = \ > $(top_srcdir)/include/odp/drv/spec/barrier.h \ > $(top_srcdir)/include/odp/drv/spec/byteorder.h \ > $(top_srcdir)/include/odp/drv/spec/compiler.h \ > + $(top_srcdir)/include/odp/drv/spec/driver.h \ > $(top_srcdir)/include/odp/drv/spec/shm.h \ > $(top_srcdir)/include/odp/drv/spec/spinlock.h \ > $(top_srcdir)/include/odp/drv/spec/std_types.h \ > -- > 2.7.4 >
On 25 October 2016 at 08:39, Brian Brooks <brian.brooks@linaro.org> wrote: > On 10/31 19:58:39, Christophe Milard wrote: >> The driver registration function (and a draft of its parameters) is >> defined, the goal being to define the driver registration framework only. >> >> Signed-off-by: Christophe Milard <christophe.milard@linaro.org> >> --- >> include/odp/drv/spec/driver.h | 76 +++++++++++++++++++++++++++++++++++++++++++ >> platform/Makefile.inc | 1 + >> 2 files changed, 77 insertions(+) >> create mode 100644 include/odp/drv/spec/driver.h >> >> diff --git a/include/odp/drv/spec/driver.h b/include/odp/drv/spec/driver.h >> new file mode 100644 >> index 0000000..467201a >> --- /dev/null >> +++ b/include/odp/drv/spec/driver.h >> @@ -0,0 +1,76 @@ >> +/* Copyright (c) 2016, Linaro Limited >> + * All rights reserved. >> + * >> + * SPDX-License-Identifier: BSD-3-Clause >> + */ >> + >> +/** >> + * @file >> + * >> + * ODPDRV driver >> + */ >> + >> +#ifndef ODPDRV_DRIVER_H_ >> +#define ODPDRV_DRIVER_H_ >> +#include <odp/visibility_begin.h> >> + >> +#ifdef __cplusplus >> +extern "C" { >> +#endif >> + >> +/** >> + * @addtogroup odpdrv_driver >> + * @details >> + * NIC driver interface to ODP > > Is 'NIC driver interface' just a pktio (pktio_if_ops_t) or is there more? The pktio is mostly what is visible on the north API, the other bit (on the north API) being the odp_load_driver() function defined in this patch serie. Roughly speaking, the idea is as follows: Drivers are either statically linked, or loaded at run-time by the application (probably during its init phase). In Both cases, drivers will be running their (__contructor__) init function which will call odpdrv_driver_register(), to register itself. odpdrv_driver_register() is an odp function belonging to the ODP south (drv) interface, hence the prefix, odrdrv_*. The registration call to odpdrv_driver_register() includes a structure telling ODP which bus the driver can handle (only PCI is the focus right now but we there make room for others), and which kind of driver is registering (some will require physical address knowledge while some other -such as pci-vfio- will not... so ODP has to know) The structure will also include pointer to the probe function of the driver, which will be called after enumeration (or possibly immediately if the driver is being loaded after enumeration has been done) > There is a packet copy in mbuf_to_pkt(), does this driver layer involve memory? Not sure I get the question... I had outlined what I though was required (as a first step), regarding memory in the following mail: https://lists.linaro.org/pipermail/lng-odp/2016-September/025695.html (note that all these should actually have been prefixed with the odpdrv_* prefix, as these funtions actually belong to the south (driver) interface. Hope this does answer your question. if not, please precise :-) > > 'odpdrv_driver' sounds like the top-most driver for the whole board or an entire > ODP implementation. Would there be other layers in this driver? odpdrv_driver: odpdrv is the prefix identifying anything belonging to ODP south (driver) interface (as odp is the prefix for the north API interface). odpdrv_driver is the part of ODP handling driver registration and init. So odpdrv_driver is not a part of any driver, it is the part of odp handling drivers. > >> + * @{ >> + */ >> + >> +/** >> + * Different busses drivers can handle: >> + */ >> +typedef enum odpdrv_bus_t { >> + UNKNOWN_BUS, /**< error case: no driver should use that */ >> + PCI /**< pci bus, for all kind of pci drivers */ >> +} odpdrv_bus_t; >> >> +/** >> + * Different driver types >> + */ >> +typedef enum odpdrv_driver_types_t { >> + UNKNOWN_TYPE, /**< error case: no driver should use that */ >> + PCI_VIRTIO, /**< pci virtio driver */ >> + PCI_VFIO /**< pci_vfio: vfio interface required */ > > Should 'PCI' be a suffix instead of a prefix? I don't think so: when many busses will be supported, having the bus name as the prefix here will nicely order the different driver types per buss. > > Could a VFIO-based driver issue R or W transactions that go over a bus other > than PCI like MDIO or maybe no bus at all? I cannot see how a driver could become bus-agnostic. I do not understanf the "no bus att all" case. > >> +} odpdrv_driver_types_t; >> + >> +/** >> + * Parameter to be given at driver registration: >> + */ >> +typedef struct odpdrv_driver_param_t { >> + const char *name; /**< Driver name. */ >> + odpdrv_bus_t bus; /**< Driver type. */ >> + odpdrv_driver_types_t type; /**< Driver type. */ >> +} odpdrv_driver_param_t; >> + >> +/** >> + * Register a Driver. >> + * A call to this function should be made by all drivers at init time. >> + * (called by an init function in the driver, probably using gcc/clang >> + * __constructor__ attribute. >> + * >> + * @param drv_param Pointer to a driver registration structure. >> + * @return 0 on success, non-zero on error. On error, drivers >> + * should release allocated resources and return. >> + */ >> +int odpdrv_driver_register(odpdrv_driver_param_t *drv_param); >> + >> +/** >> + * @} >> + */ >> + >> +#ifdef __cplusplus >> +} >> +#endif >> + >> +#include <odp/visibility_end.h> >> +#endif >> diff --git a/platform/Makefile.inc b/platform/Makefile.inc >> index b31b95b..69ee878 100644 >> --- a/platform/Makefile.inc >> +++ b/platform/Makefile.inc >> @@ -67,6 +67,7 @@ odpdrvspecinclude_HEADERS = \ >> $(top_srcdir)/include/odp/drv/spec/barrier.h \ >> $(top_srcdir)/include/odp/drv/spec/byteorder.h \ >> $(top_srcdir)/include/odp/drv/spec/compiler.h \ >> + $(top_srcdir)/include/odp/drv/spec/driver.h \ >> $(top_srcdir)/include/odp/drv/spec/shm.h \ >> $(top_srcdir)/include/odp/drv/spec/spinlock.h \ >> $(top_srcdir)/include/odp/drv/spec/std_types.h \ >> -- >> 2.7.4 >>
Minor issues to avoid names conflict. On 1 November 2016 at 15:51, Christophe Milard <christophe.milard@linaro.org > wrote: > On 25 October 2016 at 08:39, Brian Brooks <brian.brooks@linaro.org> wrote: > > On 10/31 19:58:39, Christophe Milard wrote: > >> The driver registration function (and a draft of its parameters) is > >> defined, the goal being to define the driver registration framework > only. > >> > >> Signed-off-by: Christophe Milard <christophe.milard@linaro.org> > >> --- > >> include/odp/drv/spec/driver.h | 76 ++++++++++++++++++++++++++++++ > +++++++++++++ > >> platform/Makefile.inc | 1 + > >> 2 files changed, 77 insertions(+) > >> create mode 100644 include/odp/drv/spec/driver.h > >> > >> diff --git a/include/odp/drv/spec/driver.h > b/include/odp/drv/spec/driver.h > >> new file mode 100644 > >> index 0000000..467201a > >> --- /dev/null > >> +++ b/include/odp/drv/spec/driver.h > >> @@ -0,0 +1,76 @@ > >> +/* Copyright (c) 2016, Linaro Limited > >> + * All rights reserved. > >> + * > >> + * SPDX-License-Identifier: BSD-3-Clause > >> + */ > >> + > >> +/** > >> + * @file > >> + * > >> + * ODPDRV driver > >> + */ > >> + > >> +#ifndef ODPDRV_DRIVER_H_ > >> +#define ODPDRV_DRIVER_H_ > >> +#include <odp/visibility_begin.h> > >> + > >> +#ifdef __cplusplus > >> +extern "C" { > >> +#endif > >> + > >> +/** > >> + * @addtogroup odpdrv_driver > >> + * @details > >> + * NIC driver interface to ODP > > > > Is 'NIC driver interface' just a pktio (pktio_if_ops_t) or is there more? > > The pktio is mostly what is visible on the north API, the other bit > (on the north API) being the odp_load_driver() function defined in > this patch serie. > > Roughly speaking, the idea is as follows: > Drivers are either statically linked, or loaded at run-time by the > application (probably during its init phase). > In Both cases, drivers will be running their (__contructor__) init > function which will call odpdrv_driver_register(), to register itself. > odpdrv_driver_register() is an odp function belonging to the ODP south > (drv) interface, hence the prefix, odrdrv_*. > The registration call to odpdrv_driver_register() includes a structure > telling ODP which bus the driver can handle (only PCI is the focus > right now but we there make room for others), and which kind of driver > is registering (some will require physical address knowledge while > some other -such as pci-vfio- will not... so ODP has to know) > The structure will also include pointer to the probe function of the > driver, which will be called after enumeration (or possibly > immediately if the driver is being loaded after enumeration has been > done) > > > There is a packet copy in mbuf_to_pkt(), does this driver layer involve > memory? > > Not sure I get the question... > I had outlined what I though was required (as a first step), regarding > memory in the following mail: > https://lists.linaro.org/pipermail/lng-odp/2016-September/025695.html > (note that all these should actually have been prefixed with the > odpdrv_* prefix, as these funtions actually belong to the south > (driver) interface. > Hope this does answer your question. if not, please precise :-) > > > > 'odpdrv_driver' sounds like the top-most driver for the whole board or > an entire > > ODP implementation. Would there be other layers in this driver? > > odpdrv_driver: odpdrv is the prefix identifying anything belonging to > ODP south (driver) interface (as odp is the prefix for the north API > interface). > odpdrv_driver is the part of ODP handling driver registration and init. > So odpdrv_driver is not a part of any driver, it is the part of odp > handling drivers. > > > > >> + * @{ > >> + */ > >> + > >> +/** > >> + * Different busses drivers can handle: > >> + */ > >> +typedef enum odpdrv_bus_t { > >> + UNKNOWN_BUS, /**< error case: no driver should use > that */ > >> + PCI /**< pci bus, for all kind of pci > drivers */ > >> +} odpdrv_bus_t; > to avoid potential name conflict, should these enumerations be defined with prefixes? ODPDRV_BUS_PCI, ODPDRV_BUS_UNKNOWN, ... And for below driver types: ODPDRV_PCI_VIRTIO ODPDRV_PCI_VFIO > >> > >> +/** > >> + * Different driver types > >> + */ > >> +typedef enum odpdrv_driver_types_t { > >> + UNKNOWN_TYPE, /**< error case: no driver should use > that */ > >> + PCI_VIRTIO, /**< pci virtio driver > */ > >> + PCI_VFIO /**< pci_vfio: vfio interface required > */ > > > > Should 'PCI' be a suffix instead of a prefix? > > I don't think so: when many busses will be supported, having the bus > name as the prefix here will nicely order the different driver types > per buss. > > > > > Could a VFIO-based driver issue R or W transactions that go over a bus > other > > than PCI like MDIO or maybe no bus at all? > > I cannot see how a driver could become bus-agnostic. > I do not understanf the "no bus att all" case. > > > > >> +} odpdrv_driver_types_t; > >> + > >> +/** > >> + * Parameter to be given at driver registration: > >> + */ > >> +typedef struct odpdrv_driver_param_t { > >> + const char *name; /**< Driver name. */ > >> + odpdrv_bus_t bus; /**< Driver type. */ > >> + odpdrv_driver_types_t type; /**< Driver type. */ > >> +} odpdrv_driver_param_t; > >> + > >> +/** > >> + * Register a Driver. > >> + * A call to this function should be made by all drivers at init time. > >> + * (called by an init function in the driver, probably using gcc/clang > >> + * __constructor__ attribute. > >> + * > >> + * @param drv_param Pointer to a driver registration structure. > >> + * @return 0 on success, non-zero on error. On error, drivers > >> + * should release allocated resources and return. > >> + */ > >> +int odpdrv_driver_register(odpdrv_driver_param_t *drv_param); > >> + > >> +/** > >> + * @} > >> + */ > >> + > >> +#ifdef __cplusplus > >> +} > >> +#endif > >> + > >> +#include <odp/visibility_end.h> > >> +#endif > >> diff --git a/platform/Makefile.inc b/platform/Makefile.inc > >> index b31b95b..69ee878 100644 > >> --- a/platform/Makefile.inc > >> +++ b/platform/Makefile.inc > >> @@ -67,6 +67,7 @@ odpdrvspecinclude_HEADERS = \ > >> $(top_srcdir)/include/odp/drv/spec/barrier.h \ > >> $(top_srcdir)/include/odp/drv/spec/byteorder.h \ > >> $(top_srcdir)/include/odp/drv/spec/compiler.h \ > >> + $(top_srcdir)/include/odp/drv/spec/driver.h \ > >> $(top_srcdir)/include/odp/drv/spec/shm.h \ > >> $(top_srcdir)/include/odp/drv/spec/spinlock.h \ > >> $(top_srcdir)/include/odp/drv/spec/std_types.h \ > >> -- > >> 2.7.4 > >> >
On 7 November 2016 at 08:02, Yi He <yi.he@linaro.org> wrote: > Minor issues to avoid names conflict. > > On 1 November 2016 at 15:51, Christophe Milard > <christophe.milard@linaro.org> wrote: >> >> On 25 October 2016 at 08:39, Brian Brooks <brian.brooks@linaro.org> wrote: >> > On 10/31 19:58:39, Christophe Milard wrote: >> >> The driver registration function (and a draft of its parameters) is >> >> defined, the goal being to define the driver registration framework >> >> only. >> >> >> >> Signed-off-by: Christophe Milard <christophe.milard@linaro.org> >> >> --- >> >> include/odp/drv/spec/driver.h | 76 >> >> +++++++++++++++++++++++++++++++++++++++++++ >> >> platform/Makefile.inc | 1 + >> >> 2 files changed, 77 insertions(+) >> >> create mode 100644 include/odp/drv/spec/driver.h >> >> >> >> diff --git a/include/odp/drv/spec/driver.h >> >> b/include/odp/drv/spec/driver.h >> >> new file mode 100644 >> >> index 0000000..467201a >> >> --- /dev/null >> >> +++ b/include/odp/drv/spec/driver.h >> >> @@ -0,0 +1,76 @@ >> >> +/* Copyright (c) 2016, Linaro Limited >> >> + * All rights reserved. >> >> + * >> >> + * SPDX-License-Identifier: BSD-3-Clause >> >> + */ >> >> + >> >> +/** >> >> + * @file >> >> + * >> >> + * ODPDRV driver >> >> + */ >> >> + >> >> +#ifndef ODPDRV_DRIVER_H_ >> >> +#define ODPDRV_DRIVER_H_ >> >> +#include <odp/visibility_begin.h> >> >> + >> >> +#ifdef __cplusplus >> >> +extern "C" { >> >> +#endif >> >> + >> >> +/** >> >> + * @addtogroup odpdrv_driver >> >> + * @details >> >> + * NIC driver interface to ODP >> > >> > Is 'NIC driver interface' just a pktio (pktio_if_ops_t) or is there >> > more? >> >> The pktio is mostly what is visible on the north API, the other bit >> (on the north API) being the odp_load_driver() function defined in >> this patch serie. >> >> Roughly speaking, the idea is as follows: >> Drivers are either statically linked, or loaded at run-time by the >> application (probably during its init phase). >> In Both cases, drivers will be running their (__contructor__) init >> function which will call odpdrv_driver_register(), to register itself. >> odpdrv_driver_register() is an odp function belonging to the ODP south >> (drv) interface, hence the prefix, odrdrv_*. >> The registration call to odpdrv_driver_register() includes a structure >> telling ODP which bus the driver can handle (only PCI is the focus >> right now but we there make room for others), and which kind of driver >> is registering (some will require physical address knowledge while >> some other -such as pci-vfio- will not... so ODP has to know) >> The structure will also include pointer to the probe function of the >> driver, which will be called after enumeration (or possibly >> immediately if the driver is being loaded after enumeration has been >> done) >> >> > There is a packet copy in mbuf_to_pkt(), does this driver layer involve >> > memory? >> >> Not sure I get the question... >> I had outlined what I though was required (as a first step), regarding >> memory in the following mail: >> https://lists.linaro.org/pipermail/lng-odp/2016-September/025695.html >> (note that all these should actually have been prefixed with the >> odpdrv_* prefix, as these funtions actually belong to the south >> (driver) interface. >> Hope this does answer your question. if not, please precise :-) >> > >> > 'odpdrv_driver' sounds like the top-most driver for the whole board or >> > an entire >> > ODP implementation. Would there be other layers in this driver? >> >> odpdrv_driver: odpdrv is the prefix identifying anything belonging to >> ODP south (driver) interface (as odp is the prefix for the north API >> interface). >> odpdrv_driver is the part of ODP handling driver registration and init. >> So odpdrv_driver is not a part of any driver, it is the part of odp >> handling drivers. >> >> > >> >> + * @{ >> >> + */ >> >> + >> >> +/** >> >> + * Different busses drivers can handle: >> >> + */ >> >> +typedef enum odpdrv_bus_t { >> >> + UNKNOWN_BUS, /**< error case: no driver should use >> >> that */ >> >> + PCI /**< pci bus, for all kind of pci drivers >> >> */ >> >> +} odpdrv_bus_t; > > > to avoid potential name conflict, should these enumerations be defined with > prefixes? > > ODPDRV_BUS_PCI, > ODPDRV_BUS_UNKNOWN, > ... > > And for below driver types: > > ODPDRV_PCI_VIRTIO > ODPDRV_PCI_VFIO Yes, you are 100% right here, Yi: These belongs to the ODPDRV interface and should definitively be prefixed! Thanks for picking that up. V2 sent according to your proposal. Thanks, Christophe > >> >> >> >> >> +/** >> >> + * Different driver types >> >> + */ >> >> +typedef enum odpdrv_driver_types_t { >> >> + UNKNOWN_TYPE, /**< error case: no driver should use >> >> that */ >> >> + PCI_VIRTIO, /**< pci virtio driver >> >> */ >> >> + PCI_VFIO /**< pci_vfio: vfio interface required >> >> */ >> > >> > Should 'PCI' be a suffix instead of a prefix? >> >> I don't think so: when many busses will be supported, having the bus >> name as the prefix here will nicely order the different driver types >> per buss. >> >> > >> > Could a VFIO-based driver issue R or W transactions that go over a bus >> > other >> > than PCI like MDIO or maybe no bus at all? >> >> I cannot see how a driver could become bus-agnostic. >> I do not understanf the "no bus att all" case. >> >> > >> >> +} odpdrv_driver_types_t; >> >> + >> >> +/** >> >> + * Parameter to be given at driver registration: >> >> + */ >> >> +typedef struct odpdrv_driver_param_t { >> >> + const char *name; /**< Driver name. */ >> >> + odpdrv_bus_t bus; /**< Driver type. */ >> >> + odpdrv_driver_types_t type; /**< Driver type. */ >> >> +} odpdrv_driver_param_t; >> >> + >> >> +/** >> >> + * Register a Driver. >> >> + * A call to this function should be made by all drivers at init time. >> >> + * (called by an init function in the driver, probably using gcc/clang >> >> + * __constructor__ attribute. >> >> + * >> >> + * @param drv_param Pointer to a driver registration structure. >> >> + * @return 0 on success, non-zero on error. On error, drivers >> >> + * should release allocated resources and return. >> >> + */ >> >> +int odpdrv_driver_register(odpdrv_driver_param_t *drv_param); >> >> + >> >> +/** >> >> + * @} >> >> + */ >> >> + >> >> +#ifdef __cplusplus >> >> +} >> >> +#endif >> >> + >> >> +#include <odp/visibility_end.h> >> >> +#endif >> >> diff --git a/platform/Makefile.inc b/platform/Makefile.inc >> >> index b31b95b..69ee878 100644 >> >> --- a/platform/Makefile.inc >> >> +++ b/platform/Makefile.inc >> >> @@ -67,6 +67,7 @@ odpdrvspecinclude_HEADERS = \ >> >> $(top_srcdir)/include/odp/drv/spec/barrier.h \ >> >> $(top_srcdir)/include/odp/drv/spec/byteorder.h \ >> >> $(top_srcdir)/include/odp/drv/spec/compiler.h \ >> >> + $(top_srcdir)/include/odp/drv/spec/driver.h \ >> >> $(top_srcdir)/include/odp/drv/spec/shm.h \ >> >> $(top_srcdir)/include/odp/drv/spec/spinlock.h \ >> >> $(top_srcdir)/include/odp/drv/spec/std_types.h \ >> >> -- >> >> 2.7.4 >> >> > >
diff --git a/include/odp/drv/spec/driver.h b/include/odp/drv/spec/driver.h new file mode 100644 index 0000000..467201a --- /dev/null +++ b/include/odp/drv/spec/driver.h @@ -0,0 +1,76 @@ +/* Copyright (c) 2016, Linaro Limited + * All rights reserved. + * + * SPDX-License-Identifier: BSD-3-Clause + */ + +/** + * @file + * + * ODPDRV driver + */ + +#ifndef ODPDRV_DRIVER_H_ +#define ODPDRV_DRIVER_H_ +#include <odp/visibility_begin.h> + +#ifdef __cplusplus +extern "C" { +#endif + +/** + * @addtogroup odpdrv_driver + * @details + * NIC driver interface to ODP + * + * @{ + */ + +/** + * Different busses drivers can handle: + */ +typedef enum odpdrv_bus_t { + UNKNOWN_BUS, /**< error case: no driver should use that */ + PCI /**< pci bus, for all kind of pci drivers */ +} odpdrv_bus_t; + +/** + * Different driver types + */ +typedef enum odpdrv_driver_types_t { + UNKNOWN_TYPE, /**< error case: no driver should use that */ + PCI_VIRTIO, /**< pci virtio driver */ + PCI_VFIO /**< pci_vfio: vfio interface required */ +} odpdrv_driver_types_t; + +/** + * Parameter to be given at driver registration: + */ +typedef struct odpdrv_driver_param_t { + const char *name; /**< Driver name. */ + odpdrv_bus_t bus; /**< Driver type. */ + odpdrv_driver_types_t type; /**< Driver type. */ +} odpdrv_driver_param_t; + +/** + * Register a Driver. + * A call to this function should be made by all drivers at init time. + * (called by an init function in the driver, probably using gcc/clang + * __constructor__ attribute. + * + * @param drv_param Pointer to a driver registration structure. + * @return 0 on success, non-zero on error. On error, drivers + * should release allocated resources and return. + */ +int odpdrv_driver_register(odpdrv_driver_param_t *drv_param); + +/** + * @} + */ + +#ifdef __cplusplus +} +#endif + +#include <odp/visibility_end.h> +#endif diff --git a/platform/Makefile.inc b/platform/Makefile.inc index b31b95b..69ee878 100644 --- a/platform/Makefile.inc +++ b/platform/Makefile.inc @@ -67,6 +67,7 @@ odpdrvspecinclude_HEADERS = \ $(top_srcdir)/include/odp/drv/spec/barrier.h \ $(top_srcdir)/include/odp/drv/spec/byteorder.h \ $(top_srcdir)/include/odp/drv/spec/compiler.h \ + $(top_srcdir)/include/odp/drv/spec/driver.h \ $(top_srcdir)/include/odp/drv/spec/shm.h \ $(top_srcdir)/include/odp/drv/spec/spinlock.h \ $(top_srcdir)/include/odp/drv/spec/std_types.h \
The driver registration function (and a draft of its parameters) is defined, the goal being to define the driver registration framework only. Signed-off-by: Christophe Milard <christophe.milard@linaro.org> --- include/odp/drv/spec/driver.h | 76 +++++++++++++++++++++++++++++++++++++++++++ platform/Makefile.inc | 1 + 2 files changed, 77 insertions(+) create mode 100644 include/odp/drv/spec/driver.h -- 2.7.4