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:   Sun, 16 May 2021 02:06:09 +0200 (CEST)
From:   "Maciej W. Rozycki" <macro@...am.me.uk>
To:     Arnd Bergmann <arnd@...nel.org>
cc:     netdev@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
        Paul Gortmaker <paul.gortmaker@...driver.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Doug Berger <opendmb@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Sam Creasey <sammy@...my.net>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Finn Thain <fthain@...egraphics.com.au>,
        Christophe JAILLET <christophe.jaillet@...adoo.fr>,
        Andrew Lunn <andrew@...n.ch>,
        Alexei Starovoitov <ast@...nel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        Andrii Nakryiko <andriin@...com>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        linux-kernel@...r.kernel.org, bcm-kernel-feedback-list@...adcom.com
Subject: Re: [RFC 00/13] [net-next] drivers/net/Space.c cleanup

On Sun, 16 May 2021, Arnd Bergmann wrote:

> For the ISA drivers, there is usually no way to probe multiple devices
> at boot time other than the netdev= arguments, so all that logic is left
> in place for the moment, but centralized in a single file that only gets
> included in the kernel build if one or more of the drivers are built-in.

 As I recall at least some ISA drivers did probe multiple interfaces in 
their monolithic configuration; I used a configuration with as many as 
five ne2k clones for a bridge machine for a fairly large network (~300 
machines) and as I recall it required no command-line parameters (but then 
it was some 25 years ago, so I may well not remember correctly anymore).  
It may have been with ISA PnP though (damn!).

 For modular drivers it was deemed too dangerous, for obvious reasons, and 
explicit parameters were the only way.

> * Most of ISA drivers could be trivially converted to use the module_init()
>   entry point, which would slightly change the command line syntax and
>   still support a single device of that type, but not more than one. We
>   could decide that this is fine, as few users remain that have any of
>   these devices, let alone more than one.
> 
> * Alternatively, the fact that the ISA drivers have never been cleaned
>   up can be seen as an indication that there isn't really much remaining
>   interest in them. We could move them to drivers/staging along with the
>   consolidated contents of drivers/net/Space.c and see if anyone still
>   uses them and eventually remove the ones that nobody has.

 I have a 3c509b interface in active use (although in the EISA mode, so no 
need for weird probing, but it can be reconfigured), and I have an ne2k 
clone in storage, so I could do some run-time verification if there is no 
one else available.  I'll see if I can do some driver polishing for these 
devices, but given the number of other tasks on my table this is somewhat 
low priority for me.

  Maciej

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ