> > 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? > > do you mean the exceptions part? it won't be an issue for debian/netbsd > until the next one occurs :) usually it has been alpha or mips changes > to make netbsd properly obey they ELF spec, or some such. it means that > new with an old ld.elf_so can fail.
And how are such situations handled in netbsd? Especially when aal programs are dynamically linked now? > > > 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 > > yup. I assume this means "yes". > > 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. > > ps(1) was changed to use sysctl interfaces a Long Time Ago. i've > personally verified that it works, even when running a 32 bit ps(1) > on a 64 bit sparc64 machine.... Could you please provide a more exhaustive list of kmem reading programs (if you know it?) Thanks Pavel