Re: Proposed mini-policy for NetBSD kernel packages
>
> In considering this, I realized htat we have a potentially serious problem
> - if you install a new libc on an older-kernel system, it may well blow up
> in a way that cannot easily be recovered. So I've written a mini-policy
>
> this is pretty much correct. in netbsd we basically say that if you
> have a new kernel (with old "options" enabled) an old userland should
> work fine, but new userland with old kernel is completely unsupported.
>
> covering a way to prevent this (in the absence of versioned Provides; we
> can't just Provide: netbsd-kernel (1.6.1) in any form). One thing to be
> careful of, and I'd like some refresher on this point, is whether the
> COMPAT stuff in the kernel can provide old interfaces sufficiently well
> that having, say, a -current kernel with COMPAT for 1.6.1 means you can
> sanely use 1.6.1 libc or kernel-reading tools.
>
> it is a bug if a new kernel with (all) COMPAT options is not able to
> run old software. perhaps the only exception to this is ld.elf_so,
> but in general that also applies (there *are* exceptions though.)
I don't understand this - does this mean that all dynamically linked
programs (i.e. almost all programs) will fail?
>
> [ .. ]
>
> NetBSD requires that the kernel and core libraries stay in fairly tight
> sync; to this end, a special set of meta-packages are used for Provides (to
> work around the fact that Provides can't be versioned, and the fact that a
> given kernel can support older releases, but does not always do so).
>
> as i said above, it's a bug if a new kernel fails to run old userland.
I remember our discussion about this some time ago. KVM-reading programs
can fail, while sysctl-reading should not, is this right? What programs
do depend on KVM? I guess among those are netstat and fstat. What about
ps? Its man page mentions only using /dev/kmem , not sysctl.
Bye Pavel
Reply to: