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]
Message-ID: <CAK8P3a1s58-u-T5cax+eW7_Q0=Yj7T3mfnBZSw24RErV5vCBJw@mail.gmail.com>
Date:   Sun, 1 Nov 2020 11:29:56 +0100
From:   Arnd Bergmann <arnd@...nel.org>
To:     Xie He <xie.he.0141@...il.com>
Cc:     Jakub Kicinski <kuba@...nel.org>, Arnd Bergmann <arnd@...db.de>,
        "David S. Miller" <davem@...emloft.net>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Lee Jones <lee.jones@...aro.org>,
        "Gustavo A. R. Silva" <gustavoars@...nel.org>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Krzysztof Halasa <khc@...waw.pl>
Subject: Re: [PATCH net-next] net: dlci: Deprecate the DLCI driver (aka the
 Frame Relay layer)

On Sun, Nov 1, 2020 at 12:37 AM Xie He <xie.he.0141@...il.com> wrote:
>
> On Sat, Oct 31, 2020 at 2:41 PM Arnd Bergmann <arnd@...nel.org> wrote:
> >
> > I think it can just go in the bin directly. I actually submitted a couple of
> > patches to clean up drivers/net/wan last year but didn't follow up
> > with a new version after we decided that x.25 is still needed, see
> > https://lore.kernel.org/netdev/20191209151256.2497534-1-arnd@arndb.de/
> >
> > I can resubmit if you like.
>
> Should we also remove the two macro definitions in
> "include/uapi/linux/sockios.h" (SIOCADDDLCI / SIOCDELDLCI), too? It
> seems to be not included in your original patch.

Not sure, it should probably at least be marked as 'obsolete' in the header
like SIOCGIFDIVERT, but removing the definitions might risk that someone
later reuses the numbers for a new command. I don't know if there is an
official policy for this. I see a couple of other definitions in the same file
that have no apparent implementation:
SIOCGIFCOUNT, SIOCDRARP, SIOCGRARP and SIOCSRARP. These
were still referenced in 2.6.12, but only in dead code that has since
been removed.

      arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ