On 23.02.2017 09:48, Robert Elz wrote: > 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 > Thank you for your explanation. My bump was still legitimate as I changed size of amd64 and i386 struct lwp - I removed one MD field. Testing for runtime features in the kernel is not needed in my case, I don't target NetBSD older than 8.0. I'm now working on PT_SYSCALL to dot the ptrace(2) API in my project. This shouldn't alter any structure.
Attachment:
signature.asc
Description: OpenPGP digital signature