From mboxrd@z Thu Jan  1 00:00:00 1970
From: Kamil Rytarowski <krytarowski@caviumnetworks.com>
Subject: Re: [PATCH v4 2/2] eal/linux: Add support for handling
 built-in kernel modules
Date: Wed, 9 Dec 2015 14:28:10 +0100
Message-ID: <56682C6A.8030806@caviumnetworks.com>
References: <1449513365-22282-1-git-send-email-Kamil.Rytarowski@caviumnetworks.com>
 <1449588833-485-1-git-send-email-Kamil.Rytarowski@caviumnetworks.com>
 <1449588833-485-2-git-send-email-Kamil.Rytarowski@caviumnetworks.com>
 <5667D879.9020006@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
To: Panu Matilainen <pmatilai@redhat.com>, Kamil Rytarowski
 <Kamil.Rytarowski@caviumnetworks.com>, <dev@dpdk.org>
Return-path: <dev-bounces@dpdk.org>
Received: from na01-bn1-obe.outbound.protection.outlook.com
 (mail-bn1on0057.outbound.protection.outlook.com [157.56.110.57])
 by dpdk.org (Postfix) with ESMTP id CFBA758D4
 for <dev@dpdk.org>; Wed,  9 Dec 2015 14:28:26 +0100 (CET)
In-Reply-To: <5667D879.9020006@redhat.com>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>



W dniu 09.12.2015 o 08:30, Panu Matilainen pisze:
> On 12/08/2015 05:33 PM, Kamil Rytarowski wrote:
>> Currently rte_eal_check_module() detects Linux kernel modules via 
>> reading
>> /proc/modules. Built-in ones aren't listed there and therefore they 
>> are not
>> being found by the script.
>>
>> Add support for checking built-in modules with parsing the sysfs files
>>
>> This commit obsoletes the /proc/modules parsing approach.
>>
>> Signed-off-by: Kamil Rytarowski <Kamil.Rytarowski@caviumnetworks.com>
>> Signed-off-by: David Marchand <david.marchand@6wind.com>
>> ---
>>   lib/librte_eal/linuxapp/eal/eal.c | 34 
>> ++++++++++++++++++++--------------
>>   1 file changed, 20 insertions(+), 14 deletions(-)
>>
>> diff --git a/lib/librte_eal/linuxapp/eal/eal.c 
>> b/lib/librte_eal/linuxapp/eal/eal.c
>> index 635ec36..92482a0 100644
>> --- a/lib/librte_eal/linuxapp/eal/eal.c
>> +++ b/lib/librte_eal/linuxapp/eal/eal.c
>> @@ -901,27 +901,33 @@ int rte_eal_has_hugepages(void)
>>   int
>>   rte_eal_check_module(const char *module_name)
>>   {
>> -    char mod_name[30]; /* Any module names can be longer than 30 
>> bytes? */
>> -    int ret = 0;
>> +    char sysfs_mod_name[PATH_MAX];
>> +    struct stat st;
>>       int n;
>>
>>       if (NULL == module_name)
>>           return -1;
>>
>> -    FILE *fd = fopen("/proc/modules", "r");
>> -    if (NULL == fd) {
>> -        RTE_LOG(ERR, EAL, "Open /proc/modules failed!"
>> -            " error %i (%s)\n", errno, strerror(errno));
>> +    /* Check if there is sysfs mounted */
>> +    if (stat("/sys/module", &st) != 0) {
>> +        RTE_LOG(DEBUG, EAL, "sysfs is not mounted! error %i (%s)\n",
>> +            errno, strerror(errno));
>>           return -1;
>>       }
>> -    while (!feof(fd)) {
>> -        n = fscanf(fd, "%29s %*[^\n]", mod_name);
>> -        if ((n == 1) && !strcmp(mod_name, module_name)) {
>> -            ret = 1;
>> -            break;
>> -        }
>> +
>> +    /* A module might be built-in, therefore try sysfs */
>> +    n = snprintf(sysfs_mod_name, PATH_MAX, "/sys/module/%s", 
>> module_name);
>> +    if (n < 0 || n > PATH_MAX) {
>> +        RTE_LOG(DEBUG, EAL, "Could not format module path\n");
>> +        return -1;
>>       }
>> -    fclose(fd);
>>
>> -    return ret;
>> +    if (stat(sysfs_mod_name, &st) != 0) {
>> +        RTE_LOG(DEBUG, EAL, "Open %s failed! error %i (%s)\n",
>> +                sysfs_mod_name, errno, strerror(errno));
>> +        return 0;
>> +    }
>
> Like with /sys/module, its not trying to *open* sysfs_mod_name 
> directory either so it shouldn't claim to do so.
>
> I did use plural on purpose when I said "the debug messages are 
> incorrect/misleading. It's certainly not trying to *open* these 
> directories so it should not claim to do so" in my previous mail :)
>
> - Panu -
>

Should be good now!

Thank you.