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, 16 Jun 2014 10:59:56 +0200 From: Michal Privoznik <mprivozn@...hat.com> To: David Miller <davem@...emloft.net> CC: jiri@...nulli.us, gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org, netdev@...r.kernel.org Subject: Re: [PATCH] net-sysfs: Report link speed only when possible On 16.06.2014 10:44, David Miller wrote: > From: Michal Privoznik <mprivozn@...hat.com> > Date: Mon, 16 Jun 2014 10:30:27 +0200 > >> On 16.06.2014 10:11, David Miller wrote: >>> From: Michal Privoznik <mprivozn@...hat.com> >>> Date: Mon, 16 Jun 2014 09:32:35 +0200 >>> >>>> On 13.06.2014 22:03, David Miller wrote: >>>>> From: Michal Privoznik <mprivozn@...hat.com> >>>>> Date: Fri, 13 Jun 2014 11:19:51 +0200 >>>>> >>>>>> So if I were developing brand new application I could say: I'm >>>>>> dropping all this workaround code and have it clean and require say >>>>>> 3.16 kernel at least. >>>>> >>>>> Then your application wouldn't be usable on %99 of systems for a long >>>>> long time. >>>>> >>>> >>>> How come? The application is going to be usable for as long as >>>> library/kernel APIs won't change. >>> >>> Because %99 of users are using a distribution kernel which is >>> definitely >>> going to be pre-3.16 for years. >>> >> >> That's why every distribution out there has a mechanism to install >> packages of a certain version, or those providing certain symbol, >> whatever. Or distributions can then backport some kernel patches or >> something. But, that's completely unrelated to the problem I'm fixing >> here. I don't think this bikeshedding is useful for anything, sorry. > > You're being entirely impractical. > > By restricting an application to a kernel version or behavior "via > backported patches" which doesn't even exist yet, you are foolishly > restricting your userbase. So? Users still have choice of not using my application. I'm okay with that. > > People just cope with what the current kernels support, when possible, > and that's the right thing to do because we cannot break it on them > exactly because people can depend upon the behavior. Once again, we are not breaking anything. Current applications continue to work. I don't understand why you keep writing the opposite over and over again. > > NOBODY is checking for -EINVAL returns when reading the link speed > sysfs file, and therefore by signalling it you will break > applications. That's very interesting thing to say, since even now one can experience EINVAL: # cat /sys/class/net/wlan0/speed cat: /sys/class/net/wlan0/speed: Invalid argument How do you know for sure that NOBODY is checking -EINVAL? For example libvirt does check EINVAL: http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/util/virnetdev.c;h=a551f9820b97aac41bbcb19c84d102c0ec3bd0aa;hb=HEAD#l1891 How can a kernel developer state that NOBODY isn't using possible kernel API anyway? > > So I will not apply a patch which adds that new behavior, sorry. That's okay. > > I am not willing to discuss this further, this is fundamental and > simple as far as I'm concerned. > Sure it is. That's why I'm surprised we even need to have this discussion. Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists