On Fri, 13 Sep 2024 10:07:26 +0100
Ferruh Yigit <ferruh.yi...@amd.com> wrote:
> > 4. If a distribution does not include > the dependency, I redistribute
> it with the dependency and open source,
> > this is somewhat similar to mlnx_ofed, is it publicly or freely?
> >
>
> All looks good from DPDK perspective, although it is preferred that
> dependency upstreamed to its upstream distribution.
>
> Problematic cases are like (not limited to), dependency only delivered
> if you purchase the HW, or it is distributed only if you sign some
> agreement, or you need to reach out to company and provide some
> information to be able to get the SW etc...
This policy is based on three principles:
1. DPDK test infrastructure must be able to cover the driver during
build and release process. Even if the DPDK CI does not have the
hardware, want to make sure that every release and patch still builds
and no regression slips in.
2. DPDK developers should be able to make broad changes to the internal
API's and be able to validate that all drivers still build. If a driver
depended on a non-available library, then it would likely get overlooked
and suffer bit rot.
3. DPDK is open source software, we don't want to be seen as being a way
to "open source wash" a proprietary internal driver.
My other concern is that if Linux kernel drivers are hard. Drivers that have
not been reviewed and merged into kernel.org are likely to have bugs.
For example, both KNI and igb_uio have serious issues that could be exploited
for security exploits. And if a non-upstream driver uses some unsupported API
it is going to be stuck running on some old unstable kernel version.
If DPDK depends on such an unstable driver, when the next security disaster
happens (like Crowdstrike), DPDK might get blamed but the real culprit would
be the proprietary kernel driver. Since DPDK is LF project, that might also
get involved.
This is not an absolute rule, and probably other Technical Board members
have different opinions.
