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

Re: Proposed mini-policy for NetBSD kernel packages

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

Reply to: