[gentoo-amd64] Re: Boycott Systemd

[Duncan]

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.duncan@×××.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