netdev - Re: [RFC PATCH net-next 8/8] selftests: net: Add port split test

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 3 Jun 2020 21:01:17 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Danielle Ratson <danieller@...lanox.com>, netdev@...r.kernel.org,
        davem@...emloft.net, michael.chan@...adcom.com,
        jeffrey.t.kirsher@...el.com, saeedm@...lanox.com, leon@...nel.org,
        jiri@...lanox.com, idosch@...lanox.com, snelson@...sando.io,
        drivers@...sando.io, andrew@...n.ch, vivien.didelot@...il.com,
        mlxsw@...lanox.com, Petr Machata <petrm@...lanox.com>
Subject: Re: [RFC PATCH net-next 8/8] selftests: net: Add port split test

On 6/3/2020 8:16 PM, Jakub Kicinski wrote:
> On Wed, 3 Jun 2020 11:12:51 -0700 Florian Fainelli wrote:
>> Any reason why this is written in python versus shell?
> 
> Perhaps personal preference of the author :) 
> 
> I'd be curious to hear the disadvantages, is python too big for
> embedded targets?

The uncompressed root filesystem (buildroot based) we use is 37MB
without it and becomes 55MB with python3. Compressed, we are looking at
a 16MB vs 22MB kernel+initramfs, this is a sizable increase, but still
within reason.

NFS mounting when testing network is not such a great idea unless you
have a dedicated port that you can reserve which you sometimes do not
have, that makes extending your program base a bit harder.

In general there appears to be no direction from kernel maintainers
about what scripting language is acceptable for writing selftests. My
concern over time is that if we all let our preferences pick a scripting
language, we could make it harder for people to actually run these tests
when running non mainstream systems and we could start requiring more
and more interpreters or runtime environments over time.

If there is no strong technical reason for using python, which at first
glance there does not appear to be, could we consider shell?
-- 
Florian