re: Proposed mini-policy for NetBSD kernel packages

[matthew green <mrg@eterna.com.au>]

   >    > 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.