On Sun, 31 Aug 2025 08:55:59 +0800 Moses Young <mosesyyo...@gmail.com> wrote:
> On 8/30/2025 3:57 AM, Stephen Hemminger wrote: > > On Fri, 29 Aug 2025 22:49:52 +0800 > > Yang Ming<mosesyyo...@gmail.com> wrote: > > > >> The current implementation hardcodes the socket file path to > >> /var/tmp, which has two issues: > >> > >> 1. Hardcoding absolute paths is not good practice. > >> 2. /var/tmp may not be writable in containerized or restricted > >> environments (e.g. when the filesystem is mounted read-only). > >> > >> This patch replaces the hardcoded path with a socket file name > >> (MLX5_SOCKET_FNAME) located in the DPDK runtime directory > >> returned by rte_eal_get_runtime_dir(). This ensures the socket > >> file can be created in both normal and containerized > >> environments, while maintaining uniqueness by appending the > >> process ID. > >> > >> Acked-by: Dariusz Sosnowski<dsosnow...@nvidia.com> > >> > >> Signed-off-by: Yang Ming<mosesyyo...@gmail.com> > >> --- > > Rather driver specific logging, why is there not a way in EAL log > > library to ope a diagnostic dump. > > Hi, > > Thanks for your comment. This patch is mainly an adaptation for > our product, which runs in container environments with read-only > filesystems. The goal is simply to remove the hard-coded /var/tmp > path while keeping backward compatibility with existing test cases. > > I agree that having a generic EAL facility for diagnostic dumps > would make sense in the longer term. However, I believe such > further development should be handled by the mlx5 driver > maintainers (Mellanox/NVIDIA), while this patch focuses only on > the immediate portability fix. > > Brs, > Yang Ming The point is other drivers have the same container problem. And would be good to follow conventions that containers impose.