> > 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?
it is really only a problem if someone does a partial upgrade of their
system, which means they did it manually. it's obviously not really
an issue for new installs and the upgrader will install a new ld.elf_so.
>
> > 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".
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?)
lets see:
- ipfilter (ipf, ipnat, etc.)
- dmesg
- tickadj(?)
- top
- gdb (this is a special case though - it's *supposed* to do that)
- identd used to, but may not anymore... (maybe only in -current?)
- rpc.rstatd(?)
- ccdconfig(?)
- savecore
- fstat (maybe not anymore?)
- ipcs(?)
- netstat
- nfsstat
- pmap
- systat
- vmstat
- w/uptime (maybe not?)
- ifmcstat(?)
- kgmon(?)
- mlxctl(?)
- pstat
- slstats
- trpt
- trsp
looks fairly complete if too many...
.mrg.
