Message-ID: <ad6efc07-1706-a8e2-1478-45124838a043@kernel.org>
Date:   Mon, 9 Jan 2023 09:34:26 +0100
From:   Jiri Slaby <jirislaby@...nel.org>
To:     Jan Engelhardt <jengelh@...i.de>
Cc:     Stephen Hemminger <stephen@...workplumber.org>,
        netdev@...r.kernel.org, David Ahern <dsahern@...nel.org>,
        Jonathan Corbet <corbet@....net>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Michael Ellerman <mpe@...erman.id.au>,
        Nicholas Piggin <npiggin@...il.com>,
        Christophe Leroy <christophe.leroy@...roup.eu>,
        Pablo Neira Ayuso <pablo@...filter.org>,
        Jozsef Kadlecsik <kadlec@...filter.org>,
        Florian Westphal <fw@...len.de>, Borislav Petkov <bp@...e.de>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Neeraj Upadhyay <quic_neeraju@...cinc.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Damien Le Moal <damien.lemoal@...nsource.wdc.com>,
        Muchun Song <songmuchun@...edance.com>,
        Akhmat Karakotov <hmukos@...dex-team.ru>,
        Antoine Tenart <atenart@...nel.org>,
        Xin Long <lucien.xin@...il.com>,
        Juergen Gross <jgross@...e.com>,
        Hans de Goede <hdegoede@...hat.com>,
        Nathan Fontenot <nathan.fontenot@....com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        Suma Hegde <suma.hegde@....com>, Chen Yu <yu.c.chen@...el.com>,
        William Breathitt Gray <vilhelm.gray@...il.com>,
        Xie Yongji <xieyongji@...edance.com>,
        Pali Rohár <pali@...nel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Alexandre Ghiti <alexandre.ghiti@...onical.com>,
        Chuck Lever <chuck.lever@...cle.com>,
        Jeff Layton <jlayton@...nel.org>,
        Paul Gortmaker <paul.gortmaker@...driver.com>,
        Nikolay Aleksandrov <razor@...ckwall.org>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Menglong Dong <imagedong@...cent.com>,
        Petr Machata <petrm@...dia.com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Roopa Prabhu <roopa@...dia.com>,
        Yuwei Wang <wangyuweihx@...il.com>,
        Shakeel Butt <shakeelb@...gle.com>,
        Kuniyuki Iwashima <kuniyu@...zon.com>,
        Kees Cook <keescook@...omium.org>,
        Stefano Garzarella <sgarzare@...hat.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Wang Qing <wangqing@...o.com>, Yu Zhe <yuzhe@...china.com>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        "open list:MIPS" <linux-mips@...r.kernel.org>,
        "open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)" 
        <linuxppc-dev@...ts.ozlabs.org>,
        "open list:NETFILTER" <netfilter-devel@...r.kernel.org>,
        "open list:NETFILTER" <coreteam@...filter.org>
Subject: Re: [PATCH net-next] Remove DECnet support from kernel

On 09. 01. 23, 9:14, Jan Engelhardt wrote:
> 
> On Monday 2023-01-09 08:04, Jiri Slaby wrote:
>> On 18. 08. 22, 2:43, Stephen Hemminger wrote:
>>> DECnet is an obsolete network protocol
>>
>> this breaks userspace. Some projects include linux/dn.h:
>>
>>   https://codesearch.debian.net/search?q=include.*linux%2Fdn.h&literal=0
>>
>> I found Trinity fails to build:
>> net/proto-decnet.c:5:10: fatal error: linux/dn.h: No such file or directory
>>      5 | #include <linux/dn.h>
>>
>> Should we provide the above as empty files?
> 
> Not a good idea. There may be configure tests / code that merely checks for
> dn.h existence without checking for specific contents/defines. If you provide
> empty files, this would fail to build:
> 
> #include "config.h"
> #ifdef HAVE_LINUX_DN_H
> #	include <linux/dn.h>
> #endif
> int main() {
> #ifdef HAVE_LINUX_DN_H
> 	socket(AF_DECNET, 0, DNPROTO_NSP); // or whatever
> #else
> 	...
> #endif
> }
> 
> So, with my distro hat on, outright removing header files feels like the
> slightly lesser of two evils. Given the task to port $arbitrary software
> between operating systems, absent header files is something more or less
> "regularly" encountered, so one could argue we are "trained" to deal with it.
> But missing individual defines is a much deeper dive into the APIs and
> software to patch it out.

Right, we used to keep providing also defines and structs in uapi 
headers of removed functionality. So that the above socket would 
compile, but fail during runtime.

I am not biased to any solution. In fact, I found out trinity was fixed 
already. So either path networking takes, it's fine by me. I'm not sure 
about the chromium users, though (and I don't care).

thanks,
-- 
js
suse labs

Powered by blists - more mailing lists