Thread (11 messages) flat view 11 messages, 3 authors, 2014-06-16

Re: [PATCH] net-sysfs: Report link speed only when possible

From: Jiri Pirko <jiri@resnulli.us>
Date: 2014-06-16 09:01:23
Also in: lkml

Mon, Jun 16, 2014 at 10:44:30AM CEST, davem@davemloft.net wrote:
From: Michal Privoznik <redacted>
Date: Mon, 16 Jun 2014 10:30:27 +0200
quoted
On 16.06.2014 10:11, David Miller wrote:
quoted
From: Michal Privoznik <redacted>
Date: Mon, 16 Jun 2014 09:32:35 +0200
quoted
On 13.06.2014 22:03, David Miller wrote:
quoted
From: Michal Privoznik <redacted>
Date: Fri, 13 Jun 2014 11:19:51 +0200
quoted
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.

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.

NOBODY is checking for -EINVAL returns when reading the link speed
sysfs file, and therefore by signalling it you will break
applications.

So I will not apply a patch which adds that new behavior, sorry.

I am not willing to discuss this further, this is fundamental and
simple as far as I'm concerned.
Let's just hope we do not introduce some other, more serious bug
somewhere else in user api. I see that such things are unfixable :/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help