> 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? 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. 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. 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. Thanks, Ben
