On Wed, Mar 10, 2021 at 10:33:50AM -0800, Stephen Hemminger wrote: > On Wed, 10 Mar 2021 17:27:17 +0000 > Bruce Richardson <bruce.richard...@intel.com> wrote: > > > On Wed, Mar 10, 2021 at 09:21:37AM -0800, Stephen Hemminger wrote: > > > There can be cases such as containers or other runtime environments > > > where DPDK may not be able to access the default runtime path. > > > This patch introduces DPDK_RUNTIME_DIR as an environment variable > > > to allow controlling and overriding the path. > > > > > > The example we have is DPDK application running in an untrusted > > > systemd container. In this case, it is not root, and XDG_RUNTIME_DIR > > > is not set (since it is not a user application), and /tmp is > > > blocked. The correct place for this application is to use /run. > > > > > > In any case, hard coded path assumptions are a problem. > > > > > > Signed-off-by: Stephen Hemminger <step...@networkplumber.org> > > > --- > > > > Basic question, if the user/operator can set DPDK_RUNTIME_DIR in the > > container, can they not also set XDG_RUNTIME_DIR? > > Yes they could, but more about not having hard coded paths.
As far as I can see, you aren't removing the hard-coded path to "/tmp" in your patch, so unless I'm missing something I'm not seeing the significance of the change here? It largely just seems to be adding a new environment variable on top of the existing one, while changing nothing if neither is set. /Bruce