> On Mar 7, 2017, at 6:56 AM, Thomas Monjalon <thomas.monja...@6wind.com> wrote: > > 2017-03-07 10:14, Dumitrescu, Cristian: >> From: Stephen Hemminger [mailto:step...@networkplumber.org] >>> On Mon, 6 Mar 2017 20:41:27 +0000 >>> "Wiles, Keith" <keith.wi...@intel.com> wrote: >>> >>>> Being able to add features without having to change DPDK maybe a strong >>> feature for companies that have special needs for its application. They just >>> need to add a rte_eth_capability enum in a range that they want to control >>> (which does not mean they need to change the above structure) and they >>> can provide private features to the application especially if they are very >>> specific features to some HW. I do not like private features, but I also do >>> not >>> want to stick just any old API in DPDK for any given special feature. >>> >>> >>> I understand why you make that argument, but in practice it doesn't work >>> that way. >>> When new features get added to DPDK, then the application must request >>> those features through configration and other >>> API's. Therefore building everything into eth_dev doesn't seem to be >>> helpful. >> >> Stephen, I think we are all aligned here. Question is: do you want the >> application to discover the supported capabilities through a standard API or >> do you want each capability to provide its own specific discovery mechanism >> (if any)? This patch proposes a standard API. > > Just a precision: A function with a void* parameter is not a fully defined > API. > We still need to know how to interpret the void* in each case.
One simple solution is to create inline function with the correct prototypes and a reasonable name for that function. The inline will just call the generic API providing the enum and the structure pointer converted into a void *. Using this simple method we get both solutions and adding a strong type check. Regards, Keith
