On Wed, Mar 10, 2021 at 09:52:58PM +0100, Thomas Monjalon wrote: > 12/02/2021 20:09, Tyler Retzlaff: > > Recently installation of driver headers and export of functions was > > pulled back from being public to private > > (commit > > df96fd0d73955bdc7ca3909e772ff2ad903249c6). From a discussion > > with Thomas Monjalon we understand that it was not > > the design intent to ever have these > > headers exposed publicly, but it was allowing us to > > maintain the drivers we do implement outside of the normal dpdk > > tree. > > > > We would like to propose that building driver plugins external to the > > dpdk source tree be officially supported / > > restored and it is is our > > understanding there there are asks from other DPDK consumers for the > > same. We understand the main concern is that > > it might incorrectly convey that the > > API/ABI of the driver interface is stable or promised to be > > compatible when no such promise exists.
sorry for previous mail format i didn't intend for things to be hard to read. > > Yes we must have a clean API export for application. > The driver interface should not be exported by default. agreed for both points. i think introducing another name to the set of __rte_internal, __rte_experimental, __rte_<to_be_named> is probably the mechanism to use? > > > Can the broader community help us with an acceptable solution to building > > the drivers out of the tree? Aside from > > installing the needed headers what > > other mechanical things can we do to achieve this? We are happy to > > do the work/submit the required patches as > > necessary. > > What about a meson option to export the driver interface files? i would propose driver interface files installation defaults to off and a meson option -D<to_be_named>=true has to be passed to enable installation. > Should it be exported in the same include directory as API files? that is a good question, i'm not sure there is substantial value if we are defaulting to not installing the driver interface files. but i have no objection if someone sees value in a deeper include path. > Should it be accessible with a pkg-config file? i haven't worked with pkg-config in some time, is the suggestion that we include a .pc file or something so a dependent/external driver can detect that the driver interface files are available? my first thought is no because it is an unstable api i would not want to encourage automatically finding and depending on the driver interface and instead opt for external drivers to have to jump through a few hoops. but perhaps you have other ideas in mind?
