From: Michal Privoznik <mprivozn@redhat.com>
To: David Miller <davem@davemloft.net>
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
Date: Mon, 16 Jun 2014 10:59:56 +0200 [thread overview]
Message-ID: <539EB20C.5000103@redhat.com> (raw)
In-Reply-To: <20140616.014430.163976160998454211.davem@davemloft.net>
On 16.06.2014 10:44, David Miller wrote:
> From: Michal Privoznik <mprivozn@redhat.com>
> Date: Mon, 16 Jun 2014 10:30:27 +0200
>
>> On 16.06.2014 10:11, David Miller wrote:
>>> From: Michal Privoznik <mprivozn@redhat.com>
>>> Date: Mon, 16 Jun 2014 09:32:35 +0200
>>>
>>>> On 13.06.2014 22:03, David Miller wrote:
>>>>> From: Michal Privoznik <mprivozn@redhat.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
next prev parent reply other threads:[~2014-06-16 9:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-06 8:40 [PATCH] net-sysfs: Report link speed only when possible Michal Privoznik
2014-06-06 8:57 ` Jiri Pirko
2014-06-06 19:54 ` David Miller
2014-06-13 9:19 ` Michal Privoznik
2014-06-13 20:03 ` David Miller
2014-06-16 7:32 ` Michal Privoznik
2014-06-16 8:11 ` David Miller
2014-06-16 8:30 ` Michal Privoznik
2014-06-16 8:44 ` David Miller
2014-06-16 8:59 ` Michal Privoznik [this message]
2014-06-16 9:01 ` Jiri Pirko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=539EB20C.5000103@redhat.com \
--to=mprivozn@redhat.com \
--cc=davem@davemloft.net \
--cc=gregkh@linuxfoundation.org \
--cc=jiri@resnulli.us \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.