tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/sys/sys

On 23.02.2017 09:48, Robert Elz wrote:
>     Date:        Thu, 23 Feb 2017 15:32:16 +0800 (PHT)
>     From:        Paul Goyette <>
>     Message-ID:  <>
>   | 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

Home | Main Index | Thread Index | Old Index