Frank Peters posted on Mon, 22 Sep 2014 12:21:42 -0400 as excerpted: > On Mon, 22 Sep 2014 06:00:20 +0000 (UTC) > Duncan <1i5t5.dun...@cox.net> wrote: > > >> As for the loss of the usb static device nodes, did you (Frank) file a >> bug about it breaking your userspace? That's one of Linus' most firm >> kernel rules -- you do *NOT* change the userspace/kernelspace API/ABI >> and break userspace. However, there's a known exception. Rather like >> the old philosophical question as to whether if a tree falls in the >> forest and nobody hears/sees it, did it actually fall at all, if nobody >> notices the userspace/kernelspace ABI breaking, did it really break at >> all? >> >> > Bug reports won't be considered. The removal of the kernel scanner > module was well-planned and deliberate. The new way is to use libusb to > access the scanner from user space. If it affects me then it affects > countless others (and there are many forum posts about this issue) but > these changes will not be reversed.
Perhaps, but if nobody bugged it on the don't break userspace issue... Even if the decision didn't change, such a discussion would have been useful, as at minimum it would have helped delimit the boundaries of that rule, and may well have encouraged being somewhat less bold in its pronouncements, perhaps effecting a footnote or the like where appropriate, etc. FWIW, I have a similar personal parallel, which illustrates the work- around concept rather nicely. I was running a first-gen AMD Opteron machine for 8+ years, upgrading it to dual-cores and upping the memory over time. Eventually the mobo died (bulging/bad capacitors), but well before that, some kernel broke lm_sensors for some of its temp sensors, etc. Turns out there was a problem with that and other functionality claiming the same I/O addresses that was common in hardware of that generation and the kernel was updated to be stricter about that, disabling one or the other so they didn't interfere. But either I didn't happen to use whatever else was interfering, or whatever other claim on that IO space there was wasn't actually used on my hardware, or something. Of course that didn't change the fact that lm_sensors, a userspace program, was now broken. What *DID* change it was the fact that when they made that change, they added a kernel command-line option to be less strict with those reservations, effectively returning to the old functionality. When this was pointed out on the bug I filed, I added that option to my kernel commandline, and sure enough, lm_sensors functionality was back to normal. =:^) Other times they make it a kernel option, enabling deprecated procfs or sysfs interfaces, for instance. The point being, if userspace was broken because of the change and somebody called them on exactly that, they'd have had to respond in /some/ way or other, and very likely the functionality would have remained available as a result, even if it took enabling some obscure kconfig option or adding a kernel commandline option to get it back. If not, then precedent would have been set and we'd have an established line on the limits of that rule. But someone would have had to file that bug in the first place, in ordered for that to happen. Now it's likely too late, and the "if it breaks and nobody reports it, did it actually break" clause, along with the "other software now depends on the new behavior" clause, would likely be invoked, and unless the software broken was rather high profile, it's unlikely you'd get a change. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
