From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id D76F1A00C5; Sun, 26 Apr 2020 14:50:59 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8842D1BF70; Sun, 26 Apr 2020 14:50:58 +0200 (CEST) Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) by dpdk.org (Postfix) with ESMTP id D1E7C1BF67 for ; Sun, 26 Apr 2020 14:50:56 +0200 (CEST) Received: by mail-lj1-f193.google.com with SMTP id f11so10039708ljp.1 for ; Sun, 26 Apr 2020 05:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=+PhQmEABaWpmwJ9i8w5sdGk/0lLYio53CdhBcrNDg1o=; b=iFhMBluyY/qgar5+54uy6ONQN/BQK0Z3pedjBlVDQGV9ab1XVGFeCb+i2iQ6ZQCRlI x6246mFUek2VjQciJ7I/nyjf6IXxVaLvo/CSiMvdHcl9rEtumKEKydt7NpKLZpXCT6VF vTiET3phfIfmsjuo6vKXUFn0eMg6VMsWlqJ6Su3sN3CXEu9sgiIsVFHthSy6bdT6Xjsu 1lQuNKdMITDCflVbbpZYVZ4FWgy4OuejBpcmQ4o2ITpgutZLK6ZcUN10Q4KEOc3u2NLi yvmwgphc7J3nkIhbumlpkkcj0o5tOR4uGr0y9ehRXyYlg9Wo2vxSk11qHqGFvjwMSOXC 1hAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=+PhQmEABaWpmwJ9i8w5sdGk/0lLYio53CdhBcrNDg1o=; b=R4IOZOHvC7dYVTAoFTbU5IuVhvbujYyw/ih+h1bx7TrWrC5aJSpUiMpnkMnbqkrlWb zol+husmA8sra/q0d+iXW+wjDoLDZ9Ja8ADTAc3ApA4WK0CWoQfR8MTUiDDuDb8bqW2L ZvDFgyVTlLOp9vvDzD00E/Lxu0NJ3C1dFcuW9ds7HTcvZSFtOq4FcnhVIN1Tc1yQ84rl oUQ7b/eYNmmFclC0gaYiKSeoFtcVx0CxT//A/t8jxSBfWTC/a4BUeVVrE+PLfKtOc7iR CYEw3SEMkuKFPnq58y5/ChHu/IeVxg17NamJDnKLQMQPilFEHDMTNqDC75nEpcJE8iUQ Czhw== X-Gm-Message-State: AGi0PuY8rQURVeis7KooUKgiHChWKqnIieL+s0ew8O8j0Sg+ktSLz8DT MAhwfB8OXraYFC1MImnYv0k= X-Google-Smtp-Source: APiQypLEIUZglc2AjedUD3yKQFE89gFYbK9QxoMpbd9+El7J5AWrqzqtrFuA2Szovn48tQ1lcRxjIg== X-Received: by 2002:a2e:780a:: with SMTP id t10mr11405432ljc.247.1587905456272; Sun, 26 Apr 2020 05:50:56 -0700 (PDT) Received: from Sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id 6sm8859947lfy.97.2020.04.26.05.50.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 26 Apr 2020 05:50:55 -0700 (PDT) Date: Sun, 26 Apr 2020 15:50:54 +0300 From: Dmitry Kozlyuk To: Jerin Jacob Cc: dpdk-dev , Pallavi Kadam , Narcisa Ana Maria Vasile , Ranjit Menon , Thomas Monjalon , Jerin Jacob , Sunil Kumar Kori , Bruce Richardson , Harini Ramakrishnan , Omar Cardona , David Marchand Message-ID: <20200426155054.6a757920@Sovereign> In-Reply-To: References: <20200426032245.2437733-1-dmitry.kozliuk@gmail.com> <20200426032245.2437733-3-dmitry.kozliuk@gmail.com> <20200426150202.521e7930@Sovereign> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 2/2] eal/windows: fix build by supporting trace X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 2020-04-26 17:53 GMT+0530 Jerin Jacob wrote: > On Sun, Apr 26, 2020 at 5:32 PM Dmitry Kozlyuk wrote: > > > > On 2020-04-26 17:02 GMT+0530 Jerin Jacob wrote: > > > > +/** > > > > + * Get absolute path to the directory where permanent data can be stored. > > > > + * > > > > + * @return > > > > + * Statically allocated string on success, NULL on failure. > > > > + */ > > > > +const char * > > > > +eal_permanent_data_path(void); > > > > > > Do windows have PATH_MAX kind of macro? I think, it is better API > > > consumer allocates > > > the memory of size PATH_MAX and implementation fills it, instead of, > > > the static scheme. > > > > This API falls in line with rte_eal_get_runtime_dir() and other > > eal_filesystem.h functions, that use static scheme. Logically, its result > > never changes. It is race-free and is only called during initialization. What > > you propose can be done, but are there any benefits? > > I thought who will free that memory? It looks like libc creating a static memory > for this item. so, your current eal_permanent_data_path() declarations > looks good to > me. Actually, your concern is valid (see man quotes below). Windows implementation has no such issue because of its own static buffer. I'd use static scheme in EAL interface for convenience, but change Unix implementation to copy string returned by libc into a static buffer. man 3 getenv: The string pointed to by the return value of getenv() may be statically allocated, and can be modified by a subsequent call to getenv(), putenv(3), setenv(3), or unsetenv(3). man 3 getpwuid: The return value may point to a static area, and may be overwritten by subsequent calls to getpwent(3), getpwnam(), or getpwuid(). -- Dmitry Kozlyuk