Comment # 8 on bug 1187011 from Lawrence Somerville

From the Internet I learned that SUSE stands for Gesellschaft f������r Software-und
SystemEntwicklung (Software and System Development in the English language) and
that SLE in turns stands for SUSE Linux Enterprise.  I gather from your writing
that versions of the Linux kernel which have been in time behind the latest
versions of the Linux kernel released by https://kernel.org/ on the Internet
were being used in SLE.  Therefore it makes sense that the decision to in
openSUSE use Linux kernels in use in SLE would also mean that the kernels in
use in openSUSE would have also been in time behind the version of the Linux
kernel that was most recently released by and/or through https://kernel.org/.

I gather that the numbering system for Linux kernels is such that a Linux
kernel numbered 5.13 is newer than a Linux kernel numbered 5.3 with the number
13 being larger than 3 indicating a later version of the Linux kernel when
those version numbers increase with time.  This feature differs from the fact
that the number 5.13 is smaller than the number 5.3.  Someone might mistakenly
think that, for example, version 5.10 came first, then version 5.13, then
version 5.20, then version 5.22; and then version 5.30 or 5.3 came into
existence.  A numbering system for versions of computer software, including for
Linux kernels, which might help to avoid this kind of mistaken idea, could be
to instead write the kernel versions as 5:3 and 5:13 using number-separating
colons instead of number-separating periods.

Eventually I think I ���������grasped��������� the idea of the ���������bind��������� that you mentioned.--That
is it appears to me that the users of SLE who had maintenance contracts with
SLE to help them solve software problems for the fees they paid for such
service in their maintenance contracts also wanted their SLE computer software
to be able to work with the modern-computer hardware of their computers. 
Perhaps there are no software maintenance contracts for openSUSE users, since
openSUSE is a free operating system; but there are only such software
maintenance contracts for SLE and SUSE users??  Assuming so, the openSUSE users
would not share with SUSE and SLE users an interest in keeping
software-maintenance contracts, but would share the interest with SLE and SUSE
users of desiring the Linux kernels to work well with their modern-computer
hardware.  So then comes the need to add the capabilities of modern-computer
hardware support, which are contained in the new versions of the Linux kernel,
to the older versions of the Linux kernel in SLE, SUSE, and openSUSE Linux
operating systems, which is called backporting.  And I suppose the mechanics of
such backporting would include adding to and/or modifying the source code in
the older software package entitled kernel-source or else kernel-devel to
include support for the modern-computer hardware and then compiling
kernel-source or kernel-devel to make the software packages kernel-default and
kernel-preempt; and perhaps the software packages ���������kernel-devel��������� (assuming
kernel-source is needed), ���������gcc��������� (GNU���������s Not Unix [GNU] Compiler Collection), and
���������make��������� might also be needed in such a compilation.  So I thank you, Larry
Finger, for explaining this need to backport features from new Linux kernels, I
suppose originally issued through https://kernel.org/, into older Linux kernels
in use openSUSE quite well for me!  I think you have done a good job teaching
me something here!!  Since I am, in effect, your student; and you are, in
effect, my teacher, you are welcome to correct any mistaken ideas I have here
in my understanding.  Does your backporting of computer code from modern Linux
kernels into older Linux kernels in use in openSUSE include you writing
computer source code, as well as compiling source code?

Since late July of the year 2020 I was gratefully usually successful in having
VirtualBox Guest Additions ���������built��������� for either a new version of the Linux kernel
or a new version of VirtualBox by executing the file VBoxLinuxAdditions.run
obtained from the latest released version of VirtualBox.  And note that within
probably usually just some days after a new version of VirtualBox was released,
this process was usually still successful.  So if the code to accommodate that
new version of VirtualBox had not yet been incorporated in the latest Linux
kernel version released by openSUSE, it usually did not matter!--That is such
���������building��������� of VirtualBox Guest Additions was usually still successful!  This
usual success encompassed the Linux kernel versions 5.3.18-lp152.26-default
through 5.3.18-lp152.75.1.x86_64-default released through an openSUSE
repository and VirtualBox versions 6.1.12 through 6.1.22 (If there was any
failure in such ���������building,��������� without checking all of my records, I suppose it
would have been minor and/or temporary.).  But I could not do that successfully
immediately after an update of an upgrade of Leap from version 15.2 to version
15.3 of it using Leap 15.3���������s Linux kernels 5.3.18-57.3-default or
5.3.18-57.3-preempt and VirtualBox 6.1.22���������s VBoxLinuxAdditions.run.  And, as I
discussed in the Bugzilla posting on
https://bugzilla.opensuse.org/show_bug.cgi?id=1174048,  I had even greater
trouble in Leap 15.2 after updating my upgrade of Leap from version 15.1 to
15.2 of it in July of the year 2020.  Based on your writing I assume that
computer code backported into the Linux kernel used in openSUSE Leap would have
been needed every time I had new VirtualBox Guest Additions produced by
executing VirtualBox���������s file VBoxLinuxAdditions.run following the installation
of either a new version of the Linux kernel released via openSUSE Leap���������s
repositories or a new version of VirtualBox released by Oracle Corporation. 
And note that the beginning of the kernel designation 5.3.18 has been the same
in Leap 15.2 and 15.3.  Yet in this respect I suppose that there must have been
something unusual associated with updating Leap after upgrading from at least
version 15.2 to version 15.3 which prevented the success of the command
./VBoxLinuxAdditions.run with VirtualBox 6.1.22 installed.  Assuming so,
specifically what was it?  In support of this suspicion of mine is the fact
that I could have VirtualBox Guest Additions ���������built��������� successfully using
VirtualBox 6.1.22���������s VBoxLinuxAdditions.run in an up-to-date, Leap-15.2
installation, but not with that same VirtualBox-6.1.22 version in an
up-to-date, Leap-15.3 installation using either one of the Linux kernels
supplied with it.  One obvious difference is the Linux kernel version in use:
5.3.18-lp152.75.1.x86_64 late in my use of Leap 15.2 and 5.3.18-57.3-default or
5.3.18-57.3-preempt in Leap 15.3 after my upgrade and shortly afterward update
of Leap, yet before my Linux kernel update to version 5.3.18-59.5.2.x86_64,
default and preempt, on June 16, 2021.  But my experience in Leap 15.2 was that
beginning on July 23, 2020 I at least generally had multiple successes
executing the command VBoxLinuxAdditions.run after having Linux kernel updates
installed.  Was a kernel change in an upgrade or a rapid update of an upgrade
of Leap different from a kernel update without an upgrade of Leap?  Regarding
updating Leap 15.3 after upgrading Leap 15.2 to Leap 15.3 it seems likely,
especially considering your following writing and when I suspect that there may
well be some specific things in the following general writing of yours which I
do not know: ���������openSUSE has backported a number of kernel API��������� (Applications
Programming Interface) ���������changes into their kernels. That is the reason your
builds are failing.���������  It is interesting that after updating an upgrade of Leap
that in the two instances of Leap 15.2 to Leap 15.3 and Leap 15.1 to 15.2 I had
at least some partial successes using a version of the Linux kernel used in the
version of Leap before the Leap upgrade that I did not have in the updated Leap
installation a relatively short time after that upgrade of Leap.  Therefore,
considering what you wrote, it seems that one or more of the API changes made
in the Linux kernel installed after updating or during an upgrade of Leap may
have been faulty, or in the case of the function of VirtualBox 6.1.22 in Leap
15.3, at least deficient with respect to a successful execution of VirtualBox
6.1.22���������s file VBoxLinuxAdditions.run.

After I learned the large number of changes made to a Linux kernel from my next
paragraph here, I supposed that you likely would not know all of the specific
API changes made to the Linux kernels released with Leap 15.3 and their
purposes.  In that case you could comment on whether the number of API changes
made to a Linux kernel released in a Leap upgrade is greater or not than the
number of API changes made in a version of the Linux kernel released between
two, released upgrades of Leap.  Even better might be if you could comment on
whether the number of API changes made to a version of the Linux kernel
released in a Leap upgrade that would affect the operation of Leap in
VirtualBox would be greater or not than in a Linux kernel released between two
Leap upgrades.

I had a look at the ���������change log��������� for kernel-preempt, version
5.3.18-59.5.2.x86_64.  That list of changes to that version of the Linux kernel
and/or the descriptions of those changes was quite lengthy; and I did not
closely read all of the changes posted there.  And astonishingly at the end of
that description of changes 13,759 more changes were reported to have been made
for that release of the Linux kernel which were not listed in that lengthy
description of changes!  After the Linux kernel versions 5.3.18-59.5.2.x86_64,
preempt and default, were installed, I made another test execution of the
VirtualBox 6.1.22 file VBoxLinuxAdditions.run and unfortunately again had a
failed result.  From that test I am going to attempt to attach to this report
the three output files from that test named vboxadd-install.log,
vboxadd-setup.log.A, and vboxadd-setup.log.B, after having appended ���������.A��������� or
���������.B��������� to two of those file names.  Somehow (perhaps either from uninstalling and
reinstalling virtualbox-guest-x11 and virtualbox-guest-tools or from the recent
update of the Linux kernel) I lost the file sharing capability between my
Windows ���������host��������� and Leap-15.3 ���������guest��������� operating systems using the Linux
kernel-preempt-5.3.18-59.5.2.x86_64 in a folder Windows and Leap 15.3 share via
VirtualBox; but I could gratefully have it again when booting into Leap 15.3
using the Linux kernel-preempt-5.3.18-lp152.75.1, which was probably
���������inherited��������� from my Leap-15.2 before upgrading it to Leap 15.3.

How may I learn if and when a Linux kernel version for Leap 15.3 has been
released which can work well with VirtualBox 6.1.22 when its file
VBoxLinuxAdditions.run is executed?  At the end of the ���������change log��������� for the
Linux kernel-preempt version 5.3.18-59.5.2.x86_64 I read that the command ���������rpm
-q ���������changelog kernel-preempt-5.3.18-59.5.2��������� would result in output of the
complete ���������change log��������� for that version of the Linux kernel.  That would likely
be too lengthy for most people to want to read.  But perhaps an alternate
command could be found on the Internet to write the output of a similar command
into a text file such that afterward a search for ���������VirtualBox��������� or ���������6.1.22���������
could be performed in that so-produced text file to make such searching easier
than otherwise.