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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 19 May 2014 23:36:37 +0200 From: Tilman Schmidt <tilman@...p.cc> To: David Miller <davem@...emloft.net> CC: netdev@...r.kernel.org, pebolle@...cali.nl, isdn4linux@...tserv.isdn4linux.de, isdn@...ux-pingi.de Subject: Re: [PATCH 0/4] ISDN patches for net-next David, thanks for your reply. I understand your concerns but I don't agree with them and hope I'll be able to convince you otherwise. On 19.05.2014 03:36, you wrote: > Since this has been broken for several years, you might be doing more > harm than good by trying to change things back again. You appear to assume that there is a currently working configuration which might be broken by the patch series. That is not the case. The (very few) remaining users of PPP over ISDN cope with the current situation in one of these ways: a) staying with a pre-3.0 kernel that still provides capifs b) staying with (or reverting to) the deprecated ISDN4Linux subsystem c) patching the kernel locally to fix the breakage d) staying with an old udev version that can still rename device nodes e) explicitly running commands like mv /dev/capi /dev/capi20 mkdir /dev/capi ln -s /dev/capi0 /dev/capi/0 ln -s /dev/capi1 /dev/capi/1 on every boot, typically via /etc/boot.local or similar mechanisms. f) giving up on Linux ISDN support and buying a separate router. None of these will be broken by fixing the problem in the kernel: - a), b) and f) won't notice anything unless they read the changelog and find they can at last use ISDN over CAPI with a current kernel again if they want to. - c) will notice that the local kernel patch doesn't apply anymore and happily drop it. - d) and e) may or may not notice that renaming the CAPI nodes fails because the nodes are already named correctly, but apart from a couple of log messages everything will work as before. > Why not just have capiplugin able to search for and use the names > generated now? For one, capiplugin is a pretty old piece of software. The risk of breaking it in the attempt to adapt it to the Kernel CAPI interface change is far bigger than the risk associated with reverting that change in the kernel. What's more, capiplugin is not the only software affected. /dev/capi20 is the documented standard device for CAPI 2.0 on Linux. Userspace relies on that. We would have to adapt at least libcapi20 too, and possibly an unknown number of other applications. In sum, I'm convinced the proposed patch series is the minimally invasive way of sorting out the current mess surrounding the CAPI device files. Regards, Tilman -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists