Re: [PATCH v3 1/2] net/mlx5: improve socket file path handling

[Stephen Hemminger <stephen@networkplumber.org>]

On Sun, 31 Aug 2025 08:55:59 +0800
Moses Young <mosesyyoung@gmail.com> wrote:

> On 8/30/2025 3:57 AM, Stephen Hemminger wrote:
> > On Fri, 29 Aug 2025 22:49:52 +0800
> > Yang Ming<mosesyyoung@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<dsosnowski@nvidia.com>
> >>
> >> Signed-off-by: Yang Ming<mosesyyoung@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.