From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) by dpdk.org (Postfix) with ESMTP id 24FA28E90 for ; Mon, 23 Nov 2015 14:55:47 +0100 (CET) Received: by wmww144 with SMTP id w144so105642600wmw.0 for ; Mon, 23 Nov 2015 05:55:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=jljkASxXodNJdDvIICmgpVcjw5IPdZsUOFobk/QqJEc=; b=vXjMK/IE9+i+aeJHlexvYFJjOofu07tPG2Qgn5ICqcyBuxj7qp/zXwl2D3M4SDDr/P hMCiszGxS10/YCRNzqJwoYCdrOqOR0N1bpNJLSuHxsrT2hHG0zerlX7vDUwx21srjjbz mH96SPKfQ3jjPiL+Dv4rZcw4qN1lTksO87sjXE3UYjRmZ6yoVJQvp//G5XI+OuwnXJ7V nY2kKrUVRyDa2D3Xgw36X+Tc6uBmfZOX4H10OXNN/9+zLw8KjLmP3sAFPE0IeVm9UtgS TMhS0xAW5ztP9LNRoXRrJLajOKsOZt+ntKppCk7Y0JqRCGGLdB3Lrnd0jfkkMoUoWF2b WJ/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=jljkASxXodNJdDvIICmgpVcjw5IPdZsUOFobk/QqJEc=; b=gkYTJ1rdMIwUUxKQ4HUj1JcddzIyDwUFTOkpLylQ2MzFLiDVM4gleaikR4Or3jBsqg cah+lTTzseFrhcKLlF7TgG8Fn4Ge3GNgnPy9F1yE2zYYaEeATjr+DXNlF1XoEswBcLVc eIeML8GoOiWaakx2dmDVtDOgHl2W9yZEywJxECZQBivvfklmJb5OylJEXMqL7U5hbTSe EEJAtGaP4jP5VofWnPy0KGUTa+9GGk7aw886Qq/mGNq1U7i/maYHLG/Df+G354NMn/XZ cwxTRV6D2CIBLbx6bJiwMhhkTZg9licGEnwlmbr7wMLhXkmmTUaklPzJYsaTY9P6YBFX kpXg== X-Gm-Message-State: ALoCoQmdtF3KYRsmEJRFlusIWcr36o76T0zCnl8y2e1e/i+dooY1+xpQvFu58klMA9JKcs6seEPh X-Received: by 10.194.20.35 with SMTP id k3mr30920393wje.19.1448286945686; Mon, 23 Nov 2015 05:55:45 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by smtp.gmail.com with ESMTPSA id kw2sm10025357wjb.42.2015.11.23.05.55.44 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Nov 2015 05:55:44 -0800 (PST) From: Thomas Monjalon To: Panu Matilainen Date: Mon, 23 Nov 2015 14:54:28 +0100 Message-ID: <2288290.JHOQINxEtF@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <5652FB92.2050107@redhat.com> References: <923ebe527219fa16ca91e74b416b978803056d70.1447829123.git.pmatilai@redhat.com> <5046573.RFcWRsU8GT@xps13> <5652FB92.2050107@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] eal: fix plugindir processing to be filesystem agnostic X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 13:55:47 -0000 2015-11-23 13:42, Panu Matilainen: > On 11/23/2015 12:41 PM, Thomas Monjalon wrote: > > 2015-11-23 08:04, Panu Matilainen: > >> On 11/20/2015 06:38 PM, David Marchand wrote: > >>> It looks like you would skip the symbolic links while you were not before. > >>> Intended ? > >> > >> Intended. We want to accept symlinks in the driver directory, but the > >> actual drivers are always regular files. > > > > No we use symbolic links: > > http://dpdk.org/browse/dpdk/commit/mk/rte.lib.mk?id=133b75923 > > http://dpdk.org/browse/dpdk/tree/mk/rte.lib.mk#n170 > > Those symlinks eventually point to the actual drivers which are always > regular files (and not for example directories), that is the point. > Please apply. Yes > > On the same topic, you've added a check in 9f8eb1d9: > > + if (stat(solib->name, &sb) == -1) { > > + RTE_LOG(ERR, EAL, "Invalid plugin specified: %s: %s\n", > > + solib->name, strerror(errno)); > > > > It is a regression because we cannot anymore load a plugin from > > LD_LIBRARY_PATH without specifying its full path. > > It can be tested with scripts/test-null.sh. > > How do you suggest to fix it? > > My first and foremost thought is regret over messing with -d at all, > instead of keeping with the original plan of a new -D option for > directories. Supporting directories with -d opened up all these annoying > little issues that did not exist in the original plan, and lost the > ability to disable/override the default plugindir. I keep thinking having an unique option is a good thing. If disabling the default directory is needed, we can imagine a special syntax like -d- Thanks for your work. > I suppose the fix is to only use a successful stat to determine if > something is a directory and feed everything else to dlopen() which will > then fail on its own if file is not existent. Yes sounds good. > I'll send a separate patch for the regression. Thanks