Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754701AbaFPJAF (ORCPT ); Mon, 16 Jun 2014 05:00:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:25322 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754239AbaFPJAC (ORCPT ); Mon, 16 Jun 2014 05:00:02 -0400 Message-ID: <539EB20C.5000103@redhat.com> Date: Mon, 16 Jun 2014 10:59:56 +0200 From: Michal Privoznik User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: David Miller CC: jiri@resnulli.us, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH] net-sysfs: Report link speed only when possible References: <539E9D93.9040405@redhat.com> <20140616.011148.2001285440663327901.davem@davemloft.net> <539EAB23.3020101@redhat.com> <20140616.014430.163976160998454211.davem@davemloft.net> In-Reply-To: <20140616.014430.163976160998454211.davem@davemloft.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 16.06.2014 10:44, David Miller wrote: > From: Michal Privoznik > Date: Mon, 16 Jun 2014 10:30:27 +0200 > >> On 16.06.2014 10:11, David Miller wrote: >>> From: Michal Privoznik >>> Date: Mon, 16 Jun 2014 09:32:35 +0200 >>> >>>> On 13.06.2014 22:03, David Miller wrote: >>>>> From: Michal Privoznik >>>>> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/