LWN: Comments on "Haunted by ancient history"

Haunted by ancient history

nye — Tue, 20 Jan 2015 13:09:42 +0000

>Also, the Right Thing™ (and I'm a little surprised the Windows laptop doesn't do this of its own accord unless you've missed part of the story) is that you'd leave the WiFi up in your scenario, and the IP stack will choose the Cat5 (or whatever) for all new connections while continuing to handle old connections seamlessly on the WiFi

Modern versions of Windows definitely do this; I'm not sure whether older versions do, but I'd expect so since this is a simple case of setting the metric to prefer wired over wireless connections, which I find it hard to believe has ever not been the default.

There are probably other factors at work here.

Haunted by ancient history

tialaramex — Thu, 15 Jan 2015 16:31:47 +0000

But the right way to do that is to switch off your WiFi. On my laptops I usually do this by moving the physical switch provided for this purpose. On other devices (which lack a switch) you can tell software "I don't want WiFi any more" independently of the wireless code trying to connect to a specific AP.

Also, the Right Thing™ (and I'm a little surprised the Windows laptop doesn't do this of its own accord unless you've missed part of the story) is that you'd leave the WiFi up in your scenario, and the IP stack will choose the Cat5 (or whatever) for all new connections while continuing to handle old connections seamlessly on the WiFi.

Almost twenty years ago we demonstrated running VoIP through this scenario (moving from a wireless to a wired network) with Mobile IPv6. That has yet to become a commonplace application, but it was taken as read that if you began a _new_ call it would move to the better connection with no additional technology, our work was on handling an _in progress_ call correctly.

Haunted by ancient history

Wol — Thu, 15 Jan 2015 09:45:34 +0000

> not be re-established when it drops for whatever reason

You mean, like, when the user deliberately kills it???

Okay, this is my windows laptop, but I routinely kill the wifi when I plug my laptop into a network cable, it increases my bandwidth by about three orders of magnitude!

Cheers,
Wol

Haunted by ancient history

Russ.Dill@gmail.com — Thu, 15 Jan 2015 06:19:09 +0000

As far back as I can remember on ARM (some 12-14 years), people have been complaining on mailing threads and IRC that there is something wrong with the bogomips value on new hardware X, or on new kernel version Y. And every time the answer has been the same. It's *bogus* mips, or bogus, meaningless, interpretation of processor speed.

Haunted by ancient history

nix — Thu, 15 Jan 2015 01:12:46 +0000

people remember things that break for them FAR more than they remember new features or speed. You need something way over 10:1 fix:break ratio to begin to have things break even (some people think this is over 100:1)

Exactly! I was just about to follow up and comment on how a recent SCSI breakage of mine was fixed nice and fast -- but then I realised that that 'recent' breakage was in 2013! But it still *felt* recent, because it broke the boot in a scary fashion.

One nice example of a good recent fix for me was a series of helpful responses, suggestions, and finally a quirk addition when my Simtec Entropy Key started spontaneously failing in 3.16, even though 3.17 had been out for some time and 3.18 was fairly close to release. This was a particular monster to track down because it was timing-related, intermittent, only happened after a reboot, and required physical removal of a USB device to fix. I think I rebooted 180-odd times in the process of bisecting, and had two or three wrong bisection paths due to mistaking bad commits for good ones. I couldn't ask anyone else to do this -- Entropy Keys aren't very common -- and it took me some weeks to find the time to do it, but once it was tracked down, a fix was almost immediate, even though Entropy Keys are not exactly the most crucial hardware ever, and I say that even though my firewall won't boot without its nice juicy random numbers. Now that's the right way to fix bugs! So bravo Johan! :)

Off topic aside about the confusing words "Deprecation" and "Depreciation"

k8to — Wed, 14 Jan 2015 17:15:24 +0000

NO CARRIER

Haunted by ancient history

imitev — Mon, 12 Jan 2015 10:52:35 +0000

Re- bogomips

>> Linus was unsympathetic

Unsympathetic sounds nice compared to his next post [1]. If the regression had simply been a matter of reverting the patch, one may understand the harsh language, but it seems it's not [2].
Being a/the prominent kernel dev doesn't prevent him from staying polite, especially with the various initiatives being pushed for friendler open-source communities. That's really not the kind of language that will attract new kernel developers.

+1 for the "Civility within our community will continue to be a hot-button issue in 2015" prediction (which maybe was written in light of this specific thread).

[1] https://lkml.org/lkml/2015/1/4/148
[2] https://lkml.org/lkml/2015/1/5/267

Haunted by ancient history

dlang — Mon, 12 Jan 2015 03:37:07 +0000

Once you start saying that regressions for some people are acceptable if they make things better for more people you very quickly degrade into a very bad situation

different people's estimates of how many are helped by the fix vs hurt by the regression will vary wildly.

you will end up breaking _something_ for people on a regular basis

people remember things that break for them FAR more than they remember new features or speed. You need something way over 10:1 fix:break ratio to begin to have things break even (some people think this is over 100:1)

Linux-kernel development has been there in the past, and it had a reputation for breaking users systems on a regular basis. Avoiding a repeat of this history is why Linus fights so hard against regressions.

I've reported problems with binary-only apps and seen the offending patch reverted within hours. However, if you don't run current upstream kernels, or don't report when things are broken, you can't count on anyone else reporting it either, and so it's possible for the problem to live for a long while. "Enterprise" distros make this worse due to the added lag in getting new kernels out to users, so when a problem is noticed, it make be due to a change that was made upstream years ago. Such problems still need to be reported, and as this case shows, they are taken seriously by Linus and get fixed.

Haunted by ancient history

moltonel — Sun, 11 Jan 2015 23:46:32 +0000

Just to be clear: I do think that maintaining compatibility is an essential requirement.

But there are various degrees of old, unmaintained, and incompatible. And Linux often takes what looks like a hypocritical decision on what to keep and what to remove. Where's the kernel for my devfs distro ? Can I really run this 15-years old XFree86 on 3.18 ? The "if someone notices" rule is both pragmatic and naïve. there are plenty of kernel-broken software out there. Note that the situation is worse with applications and libraries.

Having a zero-tolerance "no backward-compatibility" rule is very noble until you realize that so much stuff is broken anyway.

I'm doing the opposite of forcing people to upgrade to the latest : I'm telling them to keep running that old kernel if they need to. There are plenty of situations where this is fine. Not all security issues affect everybody. I've got plenty of systems I can't afford to update, so I just put them somewhere where they won't be exposed to threats.

And if that fails, virtualisation is easy nowadays. Bogomips can't have a decent value on most modern hardware, so I'd even have to use an emulator to get my old game working properly. Thankfully, the app that require this treatment and are in comon use should be a rarity.

Not breaking compatibility is important. But folling this rule to the extreme is silly.

http://xkcd.com/1172/

Haunted by ancient history

moltonel — Sun, 11 Jan 2015 22:56:17 +0000

If no program depends on a "real" value then great, just return a constant like "1" and be done with it. I find it unlikely that there isn't a program that uses the value in its logic (as opposed to just displaying it), but I admit I don't have an example to provide.

Haunted by ancient history

johill — Sat, 10 Jan 2015 21:24:53 +0000

I have - but the cost is too high. There's very little cost in keeping this code indefinitely - it won't get any better and new drivers might not work properly with it, but it certainly won't get any worse.

Using the old API in the new tools is just going to get it wrong anyway - there are 20 or so API versions of wext after all that all need to be treated slightly differently (they didn't care all that much for backward compatibility when those were designed ....)

So no, this isn't going to happen.

You should probably just use "iw wlan0 scan" and "iw wlan0 link" instead. Doing anything beyond those two commands with the command line is mostly not going to do what you want it to anyway.

Haunted by ancient history

ploxiln — Sat, 10 Jan 2015 19:21:20 +0000

I've used "ip" for a while. I like it. Maybe it's not obvious how to get started with it, but try these:

ip addr

ip link

ip link set dev eth1 up

ip addr add 10.0.1.5/24 dev eth1

ip route

ip addr del 10.0.1.5/24 dev eth1

It's easier to manage multiple IPv4 addresses on an interface with the ip command (that does work, and can be useful). It's also more obvious how to name vlan "interfaces" and such with arbitrary names.

Haunted by ancient history

nix — Sat, 10 Jan 2015 18:01:52 +0000

If you're willing to keep using old unmaintained software, you should be ok with using old unmaintained kernels that are still compatible with said software.

It is quite possible for old unmaintained software not to contain security holes and to work perfectly well. Software does not intrinsically rot.

It is not possible for an old unmaintained kernel not to contain security holes (for the simple reason that the kernel is one single piece of software and has holes discovered from time to time).

Thus, your proposal would force people to upgrade to the latest and greatest, no matter how much of their workflows it broke. That's not very nice to the users. (This unthinking attitude that "I use a recent version of everything, therefore so can everyone else" is a large part of what's wrong with the modern Linux world IMNSHO).

Why not move the backward compatibility layer out of kernel into libc?

nix — Sat, 10 Jan 2015 17:54:34 +0000

Sure -- but glibc is generally upgraded much *less* often than the kernel, not much more often, and a world in which you find your wireless interface is broken if you upgrade your kernel until you upgrade glibc too is not a remotely desirable one. Sure, glibc can include backward-compatibility code for old kernels, and does, but an old glibc is already released cannot contain such code. The only solution there is for the *kernel* to contain backwards-compatibility code in case it is used with an older glibc.

Since this is exactly the situation now, the only effect of your change would be to double the amount of compatibility code that would need to be retained nearly forever.

Off topic aside about the confusing words "Deprecation" and "Depreciation"

amonnet — Sat, 10 Jan 2015 14:02:12 +0000

API may not depreciate ;-)
However, maintenance costs increase over time.

API may not rot. Implementation are.

Go ask the maintainers...

+++

Off topic aside about the confusing words "Deprecation" and "Depreciation"

tialaramex — Sat, 10 Jan 2015 13:01:15 +0000

Depreciation is when things are worth less over time, for example a normal family car will depreciate - you can't buy a mid-range Ford Mondeo, drive it for a couple of years and sell it for the same or more money. Much as we joke about "code rot" APIs do not depreciate.

Deprecation is when things are no longer approved, for example the gets() C library function is deprecated - there are very few cases where it could be possible to use it safely so it's better no-one uses it at all and modern compilers may warn if it is used.

Haunted by ancient history

riking — Sat, 10 Jan 2015 09:41:51 +0000

> As far as site survey is concerned (iwlist scan) - there's another interesting quirk here: if you have too many APs in the environment, iwlist/wext will stop working and report only errors and no networks at all. This is an inherent design flaw that comes from having to fit the entire list of APs into a single buffer that's limited to 64KiB, and no way to fetch the list incrementally (like nl80211 which uses netlink dump functionality). People have run into this in big deployments (usually when there's also a lot of data in the beacons which eats up the buffer quickly.)

Just wondering here - have you considered turning iw into a argv[0]-switching binary, which calls the old APIs when it *absolutely needs to* (the separate SSID and frequency setting...) but otherwise uses the new APIs when it results in the same or a consistent output?
(consistent: displaying all the huge number of networks instead of crashing. $5 says nobody depends on iwlist crashing with too many networks.)

I routinely use plain 'iwconfig' and 'ipconfig' as debugging tools - "what's my network?". It seems like the diagnostics should be possible with just the new APIs.

Haunted by ancient history

amonnet — Sat, 10 Jan 2015 08:30:03 +0000

Don't break userspace is a nice policy.

A well defined depreciation process could help in that.
Ex: this interface will disappear in 4.0; update your userspace before so that it doesn't break.

I'm sure it's better to have nice depreciation than unmaintened interface.

(Apply this to drivers too!)

+++

Haunted by ancient history

dlang — Sat, 10 Jan 2015 02:29:49 +0000

As I read Linus' message, he was saying that some value needed to be there, even if it was known to have n relation to reality (because software broke if it wasn't there to read). In your posts it sounded like you were saying that there needed to be an option to provide a "real" value. That's a much more demanding option than just having some value there.

Haunted by ancient history

moltonel — Sat, 10 Jan 2015 01:07:19 +0000

If the change can go unnoticed (in other words if the value is good enough) you can be sure that some naive programmer will use it for new work. Using bogomips was already "obviously wrong" 10 years ago, and programmers still used it.

If you want naive programmers to notice you need an even wrong-er value like "1" or "not implemented", but that'll raise compatibility red flags. But if those wrong-er values are configurable...

Haunted by ancient history

moltonel — Sat, 10 Jan 2015 00:52:16 +0000

We may disagree on the maths but we agree on the basic observations; I'm not sure what you're trying to add ?

Since Linus has decreed that bogomips should be kept, we should keep it in the form that applications expect. We all know that that form is completely broken, but that's irrelevant. Apps ask a stupid question, and Linux gives a stupid answer in the name of retrocompatibility. That's what Linus asked for, and I'm not in a position to disagree.

What I *can* suggest is to take measures today so that in many years the compatibility argument gets weak enough to be ignored. Making bogomips configurable is such a measure, a pretty standard deprecation strategy (even if the time between deprecation and removal is huge).

Haunted by ancient history

dlang — Fri, 09 Jan 2015 23:33:56 +0000

> if you get within 20% of the ideal value it's good enough.

you can't get it within 200% of the ideal value, it may not be possible to get it within 2000% of the ideal value. And the ideal value will change from time to time with no notice.

any software the uses delay loops is broken on a multi-user or even multi-application machine, let alone using bogomips to calibrate such loops.

That said, breaking software that's doing the wrong thing still isn't acceptable. Even if the software is maintained, getting the new version into the hands of users can take a LONG time. Rsyslog is very actively maintained and is on v8.6 right now. We still get people asking questions about v3.x, which was out of date in 2006.

Haunted by ancient history

moltonel — Fri, 09 Jan 2015 22:28:12 +0000

Whatever the definition used to be, how far can you count in 1ms or something. It really doesn't matter. Call it BELIEVABLE or USABLE if you think that REAL gives a false sense of correctness.

The point is that some (buggy but kernel-supported) software will use it to calibrate some kind of performance loop. So try to give them a usable value; if you get within 20% of the ideal value it's good enough. Don't go beyond the call of duty trying to give a "good" value to something that is bogus by design.

That said, I think (as a user) that the kernel's no-breakage stance is too strict. If you're willing to keep using old unmaintained software, you should be ok with using old unmaintained kernels that are still compatible with said software. I'd have been happy to see bogomips disappear from Linux immediately. But if you're not willing to do that today, please at least prepare things so that we can do it in a few years.

Haunted by ancient history

dlang — Fri, 09 Jan 2015 20:20:04 +0000

what is "REAL bogomips"? especially on systems that change the cpu frequency and/or have different cores running at different frequencies?

Haunted by ancient history

cesarb — Fri, 09 Jan 2015 14:19:27 +0000

Take a look at http://wiki.openwrt.org/doc/uci/wireless. I'd guess it's the basic_rate and require_mode options.

Haunted by ancient history

moltonel — Fri, 09 Jan 2015 13:58:58 +0000

+1, but make it configurable. Some software apparently *does* make use of bogomips, and we apparently want to avoid breaking them even more than they broke themselves.

* CONFIG_BOGOMIPS_REAL for software that actually needs it
* CONFIG_BOGOMIPS_FAKE for software that reads it but will still function with a low value
* CONFIG_BOGOMIPS_NONE for modern systems

Prefer none over fake over real, and let users/distributions bug upstream about broken software. Voilà - it'll only take a decade to get rid of bogomips completely.

Haunted by ancient history

johill — Fri, 09 Jan 2015 13:38:10 +0000

All of that already exists. If you're running wpa_supplicant, you can never have any of these problems [even with wext, since wpa_supplicant is smarter than the average user]

However, if you're not running wpa_supplicant, then it really only leaves the kernel to remember it, or the user to re-enter it every time. iwconfig/wext went with the former (and in turn got all the associated problems), iw/nl80211 went with the latter to avoid those problems.

Haunted by ancient history

johill — Fri, 09 Jan 2015 13:36:49 +0000

You can't set it using command line tools - this is only advertised and enforced by hostapd. You have to set it in the hostapd configuration file (basic_rates= option). To require HT (11n), set require_ht=1, to require VHT (11ac) set require_vht=1.

One OpenWRT, you might be able to inject options, not sure off the top of my head.

Haunted by ancient history

mathstuf — Fri, 09 Jan 2015 11:52:24 +0000

Lazy defaults for quality settings in a game? I'd think it'd be better to just run a series of renders and drop quality until you hit your target though.

Haunted by ancient history

alankila — Fri, 09 Jan 2015 05:40:07 +0000

One of the issues here is that *someone* has to remember the values set. It's either in user space of kernel space. If the kernel remembers it, then anyone can query the kernel APIs to figure out what the current wireless settings that have been told to hardware are. If it's in user space, I can imagine someone writing another dbus API for wireless connections, and adding a permanent daemon to keep track of the info.

Historical unix style favors the former, so the kernel services user processes by keeping track of important state for them, because the processes themselves are short-lived and can't do it. Modern unix style is about running everything imaginable in separate daemons. Anyway, someone can just go ahead and define the dbus API for wpa_supplicant or something, and then tell everyone to implement that.

Haunted by ancient history

mina86 — Fri, 09 Jan 2015 02:41:37 +0000

I say, just print constant 1.

Haunted by ancient history

jschrod — Fri, 09 Jan 2015 02:06:00 +0000

If you want that people use iw instead of iw*, I would recommend that some volunteer invest the time to write a good man page and get that into the distributions.

Oh, to note: Transforming the output of "iw help" into a man page would not make it a _good_ one.

Until that happens, I suppose that many CLI users (like myself) continue to use the old well-documented iw* commands.

Just as an example: How do I determine txpower with your shiny iw command? No hint at all in "iw help".

Haunted by ancient history

dlang — Thu, 08 Jan 2015 23:04:23 +0000

> Regarding your other question, it is possible for the AP to require that the client be capable of certain bitrates - they're called "basic rates", you might have such a configuration. It's also possible to require HT or even VHT to be supported. I have no idea if typical APs have configuration options in their limited web UI for that though - if you were to run hostapd (say on OpenWRT) it'd be simple to set this in the configuration file.

how would I set this with command line tools? (once I know that, I can go figure out how to set this in the distro config). I am using OpenWRT on these routers.

Haunted by ancient history

johill — Thu, 08 Jan 2015 22:51:58 +0000

Well, no, it only keeps track of the data for wext. There's currently not even a way in the API of nl80211 to transport just such single values.

I don't believe that it's better to mess up the nl80211 APIs with such stateful problems than keeping the old wext support around - at least the latter can easily be disabled and if it is people can determine relatively quickly why things broke (we never ship wext to our customers, for example, and will not support it).

If we added stateful problematic API to nl80211 we'd have the worst of both worlds, because we'd have to support the mess with all the unclear semantics of when to start connecting in the new API. That's really not worth it at all, even if it would allow us to get rid of all the other ugly wext code (and believe me - there's a lot, down to 32/64 userspace compat code that always builds two messages for the same thing because they differ etc.)

Regarding your other question, it is possible for the AP to require that the client be capable of certain bitrates - they're called "basic rates", you might have such a configuration. It's also possible to require HT or even VHT to be supported. I have no idea if typical APs have configuration options in their limited web UI for that though - if you were to run hostapd (say on OpenWRT) it'd be simple to set this in the configuration file.

Haunted by ancient history

johill — Thu, 08 Jan 2015 22:46:13 +0000

Not sure - from a brief look the API doesn't seem to have this, for whatever reason. Certainly not intentional.

Haunted by ancient history

dlang — Thu, 08 Jan 2015 22:32:54 +0000

well, if the kernel keeps track of the data for iwconfig, you should be able to use that same mechanism to allow iw to work.

Yes, it's a permanent wart, but if it lets you get rid of the rest of the support in a decade or so (after the new version of iw gets out to all the distros, it's better than keeping everything around.

And just declaring that you aren't going to support the old version isn't really a solution, if tools are depending on it, any change that is made that accidentally breaks the old version is going to require that that change get reverted (or the old code modified to work with the new change)

changing topics, is there a way to configure an interface not to use slow speeds? I'd like to configure some equipment so that if the only way it can talk to another device is at speeds <11Mb, refuse to connect to it, but I haven't been able to find a way to do this on my WNDR3800 router.

Haunted by ancient history

cesarb — Thu, 08 Jan 2015 22:17:57 +0000

> I don't believe that there's much that is possible with iwconfig/iwlist that you cannot do with iw at all, other than some esoteric settings like modifying sensitivity that no modern hardware supports anyway. I certainly haven't used iw* in many years.

I recently found something that you cannot do with iw at all. I was curious to know the transmission power of my network card.

$ iwlist wlp3s0 txpower
wlp3s0 unknown transmit-power information.

Current Tx-Power=15 dBm (31 mW)

I couldn't find a way to do that with iw. This is most annoying in the openwrt router I have, since it doesn't have iwlist installed by default (and it makes no sense to install it for just this single use); I have to use the web interface (which does show the current txpower).

This is made more annoying by the fact that iw *does* know how to set the txpower; why doesn't it have a way to get it?

dev <devname> set txpower <auto|fixed|limit> [<tx power in mBm>]
Specify transmit power level and setting type.

Haunted by ancient history

johill — Thu, 08 Jan 2015 21:35:49 +0000

> If you can specify a wildcard for channel/frequency with iw, then you should be able to emulate the iwconfig commands that didn't specify them.

No, you didn't quite understand my cooking analogy I think. iwconfig requires that the kernel keep track of the previously configured settings, and allows you to modify them later. With nl80211, the kernel will forget everything it did when it disconnects.

Say you have a network on channel 11 (2462 MHz) called "my-network".

With iwconfig you can now say

iwconfig wlan0 essid "my-network"
(it connects to your network)
iwconfig wlan0 freq 2412
(it disconnects, and fails to reconnect since there's no network on channel 1)
iwconfig wlan0 freq 2462
(it connects again to the original network)

with iw/nl80211 you don't have this option.

You can say
iw wlan0 connect "my-network"
(and it will connect)

or
iw wlan0 connect "my-network" 2412
(and it will fail to connect)

or
iw wlan0 connect "my-network" 2462
(and it will connect again)

But the kernel will not remember [1], upon disconnection, that you had previously wanted some SSID. To emulate it completely, you'd thus have to store state somewhere (filesystem? shared memory? ...?) which gets complex really quickly.

This is really intentional though - having the kernel keep state means that the kernel needs to guess when it should start doing something. This is like my cooking analogy, there's no way for the kernel to know when it should start cooking. [2]

As far as site survey is concerned (iwlist scan) - there's another interesting quirk here: if you have too many APs in the environment, iwlist/wext will stop working and report only errors and no networks at all. This is an inherent design flaw that comes from having to fit the entire list of APs into a single buffer that's limited to 64KiB, and no way to fetch the list incrementally (like nl80211 which uses netlink dump functionality). People have run into this in big deployments (usually when there's also a lot of data in the beacons which eats up the buffer quickly.)

I don't believe that there's much that is possible with iwconfig/iwlist that you cannot do with iw at all, other than some esoteric settings like modifying sensitivity that no modern hardware supports anyway. I certainly haven't used iw* in many years.

[1] and that's really intentional, if the kernel were to remember some data you get into the strange situations where to switch from one network to the other the kernel might try to connect to the old network on the new channel, or the new network on the old channel, or similar. With open networks this really isn't a problem, but with encrypted or potentially rogue networks you really don't want to even attempt to connect to a new network with half of the old configuration. Forcing userspace to commit the entire needed configuration at once easily side-steps that issue and made the whole mechanism far easier to extend to new spec updates as well.

[2] Jean actually invented SIOCSIWCOMMIT for this purpose, which in theory would have allowed you to set all the parameters and then commit them all together. However, that came too late - since it wasn't designed into the API from the beginning there was no way for the kernel to require it since that would also have broken older userspace.

Haunted by ancient history

dlang — Thu, 08 Jan 2015 20:38:29 +0000

not all uses of wifi are clients connecting to wpa servers

I use the iw* commands quite a bit when I'm looking at what's around, doing a site survey to layout new APs, etc.

I haven't tried the iw command (I had never heard of it before this problem showed up)

If you can specify a wildcard for channel/frequency with iw, then you should be able to emulate the iwconfig commands that didn't specify them.

What else is possible with the iw* commands that isn't possible with iw?

Haunted by ancient history

reubenhwk — Thu, 08 Jan 2015 20:12:16 +0000

I'm having trouble envisioning any use-case where somebody would need to know the speed of the processor... Why is anybody using bogomips in code anyway?