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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAJht_EOk43LdKVU4qH1MB5pLKcSONazA9XsKJUMTG=79TJ-3Rg@mail.gmail.com>
Date:   Fri, 30 Oct 2020 22:10:42 -0700
From:   Xie He <xie.he.0141@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     "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>, Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH net-next] net: dlci: Deprecate the DLCI driver (aka the
 Frame Relay layer)

On Fri, Oct 30, 2020 at 8:07 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> This code has only seen cleanup patches since the git era begun -
> do you think that it may still have users? Or is it completely unused?

I don't think it is still used. But I don't have solid evidence. So I
asked people in the warning messages to move to the newer HDLC Frame
Relay layer.

Some evidence indicating this is not in use might be:

1. In "Documentation/networking/framerelay.rst", in the last
paragraph, the link for the user space programs needed for
configuration has been broken.

2. The Frame Relay layer supports only one hardware driver in the
kernel. I looked up the hardware on the vendor's website, and it
seemed they had their own drivers for the hardware. I guess most users
would use the driver provided by the vendor instead.

The names of the hardware supported by our sdla.c driver appear in this page:
    http://ftp.sangoma.com/technote/INDEX
According to this file in the same directory, the driver provided by
the vendor is named WANPIPE and supports multi-protocol (unlike sdla.c
/ dlci.c but similar to hdlc_fr.c):
    http://ftp.sangoma.com/technote/tn0015.txt
According to the WANPIPE installation guide here, the vendor
explicitly requested users to disable dlci.c in the kernel, by
answering NO to CONFIG_DLCI:
    http://ftp.sangoma.com/linux/current_wanpipe/doc/WanpipeInstallation.pdf

3. According to drivers/net/wan/Kconfig, sdla.c (the only hardware
driver dlci.c supports) depends on CONFIG_ISA. According to Wikipedia,
ISA is an old 16-bit bus system. I think this makes users of this
hardware driver rare.

4. Frame Relay itself is an old technology. I'm not clear about its
overall usage but if it's still used its usage must be declining.

> The usual way of getting rid of old code is to move it to staging/
> for a few releases then delete it, like Arnd just did with wimax.

Oh. OK. But I see "include/linux/if_frad.h" is included in
"net/socket.c", and there's still some code in "net/socket.c" related
to it. If we move all these files to "staging/", we need to change the
"include" line in "net/socket.c" to point to the new location, and we
still need to keep a little code in "net/socket.c". So I think if we
move it to "staging/", we can't do this in a clean way.