linux-kernel - Re: [PATCH net-next] net: dlci: Deprecate the DLCI driver (aka the Frame Relay layer)

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 for Android: free password hash cracker in your pocket

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

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