Re: CVS commit: src/sys/sys

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 23 Feb 2017 15:32:16 +0800 (PHT)
    From:        Paul Goyette <paul%whooppee.com@localhost>
    Message-ID:  <Pine.NEB.4.64.1702231527400.4219%speedy.whooppee.com@localhost>

  | On Thu, 23 Feb 2017, Kamil Rytarowski wrote:
  | 
  | > I'm evaluating it from the osabi (pkgsrc term) point of view. I'm
  | > targeting LLDB for 7.99.62+.

The kernel version number is a horribly blunt, and very ineffetive tool,
to use for this purpose - much better is to use a feature test, where the
user level code tests for the presence of a symbol (#define) in the
appropriate header file.

If run time testing is required (which is useful far less often than you
might think) then a run time feature test (either just try the interface
and see if it works, or add an option/flag to the API which allows an
explicit test).

  | Other reasons might include
  | 
  | * changes to the contents of prop-libs that are passed between kernel
  |    and userland, or kernel and modules

Not sure about that one, but I'd expect that kernel-user proplib interactions
need versioning if some incompatibility is introduced, I don't think a
kernel version bump will normally achieve anything.

  | * changes to structs that might be included in ioctl args

That one definitely needs versioning, and not a kernel version bump.

Of course, for both of those, if the interface changed is a very new one
(as in "this ioctl/proplib was introduced last week, but we forgot...")
then just change it - anything that was built to use the (previous version
of) the new interface can just get recompiled.

  | * changes to things that kmem grovelers chase

I don't think kernel version bumps really help there either - for those
I think it is normal just to expect that a kmem groveller (of which there
are not many left, fortunately) might need to match the kernel version if
it is to be expected to work.   That is, if you boot a new kernel, you're
likely to have to rebuild those things (if you need them - it has been a
long time since I was last bothered by one of those failing, whatever the
difference between the version of user level code and the kernel)

The internal interface between kernel and modules (ie: making sure the
correct modules get loaded for the kernel) is 99% of the demand for kernel
version bumps.   Changing the sizes of kernel structs is the most common
change that requires a change, and altering the prototype of a non-static
function is another fairly common one (adding/deleting an arg, or changing
types) is another.

kre