Claudio Jeker <cje...@diehard.n-r-g.com> wrote:
> > @@ -443,7 +443,7 @@ struct kinfo_proc {
> >
> > int32_t p_vm_rssize; /* SEGSZ_T: current resident set size
> > in pages */
> > int32_t p_vm_tsize; /* SEGSZ_T: text size (pages) */
> > - int32_t p_vm_dsize; /* SEGSZ_T: data size (pages) */
> > + u_int64_t p_vm_dsize; /* VSIZE_T: data size (pages) */
> > int32_t p_vm_ssize; /* SEGSZ_T: stack size (pages) */
> >
> > int64_t p_uvalid; /* CHAR: following p_u* members from
> > struct user are valid */
>
> From my understanding this is not how struct kinfo_proc should be modified.
> Instead the code should add the u_int64_t version at the end and leave the
> old in place. This way old userland still works with new kernel.
If this is done as a size-change inline as Greg suggested, then it is a
large sysctl ABI bump, with temporary breakage until binaries catch up.
If the 32-bit value is kept as-is, and a 64-bit one is appended, this is
still a small sysctl ABI bump depending on what uses the field. Existing
binaries will use the 32-bit field for a time. Such as ps(1).
Obviously we cannot add a new 64-bit field at the end, and mark the
32-bit field "unused", it breaks many utilities in a similar fashion.
A truncated value must be put into the 32-bit field, or it is just as
akward as a large sysctl ABI bump.
Or we could coordinate the Greg approach as a sysctl ABI change near a
libc major bump. On the other side of such a bump, all kernel + base +
packages are updated to use the new storage ABI. We get orderly .h
files without a confusing glitch, and kern_sysctl.c doesn't need to
store the value into two fields (32bit and 64bit) for the forseeable
future.
Over the years I've arrived at the conclusion that maintaining binary
compatibility at all costs collects too much confusing damage. Instead,
we've built an software ecosystem where ABI changes are expected and
carry minimal consequence.
