Stephen Morris writes:
On 12/7/18 9:28 am, Sam Varshavchik wrote:
> Stephen Morris writes:
>
>> and that installed all the package updates that caused the conflicts. Having
>> done this I was able to complete the upgrade to F28, but now I have big
>> problems.
>>
>> Under F28 my USB network device doesn't work because dkms can't compile
the
>> driver for it, and, either because of this failure or a compile failure the
>> drivers for my mouse haven't been installed by dkms either.
>
> Pardon the interruption, but are you saying that you need to use a binary
> blob for a mouse? A mouse?
>
> What kinds of a mouse needs a binary blob driver?
I have a bluetooth gaming mouse which has 5 or 6 different drivers to
provide all the functionality the mouse is capable of, and all of these
drivers are linked into the kernel.
The mouse is a Razor Orochi.
The problem is that there is absolutely no guarantee whatsoever insofar as
API and ABI compatibility across Linux kernel versions. Internal APIs
between major internal kernel components don't change much, over time. But
when it comes to things like low-level device drivers, you've got no
guarantees that the same source can be compiled against the next kernel
release, unchanged.
The only way to guarantee that a particular driver's code will compile with
the next kernel is for that driver to be a part of the mainline kernel.
That's not an absolute, 100% guarantee, but it's the best that can be hoped
for. If you have a particular driver that was built for a particular kernel
version, but it's not part of the mainline kernel itself, maybe it will
still compile and work properly against the next kernel version, or maybe it
will not. And if it doesn't, there is no magic button one can push, or one
some magic rpm can be installed, to make it compile. One will have to look
the actual compilation error, look at the previous kernel's source, look at
the current kernel's source, figure out what's changed, and figure out what
needs to be changed, in the driver's source, to update it to your current
kernel's version.
For your use case, Fedora is not going to work very well, with new kernel
version updates almost every week. Practically, you should be using Linux
distribution with a stable kernel, that will backport any bug fixes to its
stable kernel version; like Centos/RHEL or Ubuntu LTS. That's what those
distros are for: to provide a stable kernel for the lifetime of the release,
that third party hardware OEM can target their custom kernel drivers for.