Hi Thomas, > -----Original Message----- > From: Thomas Monjalon <tho...@monjalon.net> > Sent: Thursday, October 14, 2021 3:00 AM > To: Harris, James R <james.r.har...@intel.com>; Walker, Benjamin > <benjamin.wal...@intel.com> > Cc: Liu, Changpeng <changpeng....@intel.com>; Xia, Chenbo > <chenbo....@intel.com>; David Marchand <david.march...@redhat.com>; > dev@dpdk.org; Aaron Conole <acon...@redhat.com>; Zawadzki, Tomasz > <tomasz.zawad...@intel.com> > Subject: Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs > > 13/10/2021 19:56, Walker, Benjamin: > > > From: Thomas Monjalon <tho...@monjalon.net> > > > > > > In order to be perfectly clear, all the changes done around this option > > > enable_driver_sdk share the goal of tidying stuff in DPDK so that ABI > becomes > > > better manageable. > > > I think that nobody want to annoy the SPDK project. > > > I understand that the changes effectively add troubles, and I am sorry > about > > > that. If SPDK and other projects can manage with this change, good. > > > If there is a real blocker, we should discuss what are the options. > > > > > > Thanks for your understanding > > > > I completely understand the desire to make the ABI manageable. If I were in > your shoes, I'd be doing the same exact thing. What I don't currently > understand is the motivation behind this enable_driver_sdk option. My guess is > that it's one of two things. > > > > \1 ABI manageability: You say that's the purpose above, and that was my > initial assumption. But wouldn't that necessarily mean, over time, no longer > considering the symbols that were defined by the header files as part of the > stable ABI? > > Absolutely. The idea is that we don't guarantee ABI for the drivers. > > > If you still consider these symbols as part of the ABI in shared library > builds, then the enable_driver_sdk option does absolutely nothing to improve > the ABI situation, so why bother to have it at all? We can't have packaged > SPDK relying on symbols in a packaged DPDK that are not part of the official > ABI. > > > \2 Not supporting out-of-tree drivers: Another option is that you just don't > want people writing out of tree drivers. > > We don't want complications due to support of out-of-tree drivers, > but we don't want to forbid them. > > > You can't just drop it outright because people already do it, > > but you'd like to not support it for shared library builds at least. > > I didn't think about it in these terms. > But saying we don't offer compatibility for shared library drivers > is not too far of "no support" indeed. > > > So I'd like to really understand which of these two motivated the > enable_driver_sdk option . Maybe it's not even one of the two above. If it is > #1, then I think maybe we can work with DPDK to define a very small set of > out-of-tree driver APIs/ABIs that need to continue to exist in the shared > libraries by default. I do think SPDK needs only a very small number. If it's > #2, then that's the entire SPDK use case and I'd ask you to reconsider the > direction. > > Yes I think we need to agree on functions to keep as-is for compatibility. > Waiting for your input please.
So, do you mean currently DPDK doesn't guarantee ABI for drivers but could have driver ABI in the future? Thanks, Chenbo >
