Messages in this thread | | | Date | Mon, 9 Jan 2023 09:34:26 +0100 | Subject | Re: [PATCH net-next] Remove DECnet support from kernel | From | Jiri Slaby <> |
| |
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
| |