Re: lib/39631: uvm_extern.h got corrupted to current

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR lib/39631; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: matthew green <mrg%eterna.com.au@localhost>
Subject: Re: lib/39631: uvm_extern.h got corrupted to current
Date: Mon, 25 Oct 2010 01:36:55 +0000

 On Mon, Sep 29, 2008 at 04:59:45AM +1000, matthew green wrote:
  >     > while tring to get bubblemon-dockapp alive, it complained about
  >     > missing element of struct uvmexp i checked docs, and the element
  >     > active is supposed to be there in the struct. I checked
  >     > /usr/include/uvm/uvm_extern.h and struct uvmext looks like:
  >     > [snip]
  >    
  >    This is not "corruption", nor is it a "regression"; that element was
  >    intentionally removed from struct uvmexp.
  >    
  >    It appears that uvm(9) was not updated to reflect this.
  >    
  >    It also appears that this bubblemon-dockapp is broken; it should be
  >    using struct uvmexp_sysctl and the VM_UVMEXP2 sysctl to get it, rather
  >    than struct uvmexp and VM_UVMEXP.
  > 
  > 
  > if VM_UVMEXP is returning different info then someone has broken it.
 
 Whee, I appear to have had this marked to write a reply "later" for
 two years.
 
 Anyway, it appears that the point of struct uvmexp_sysctl is/was to
 provide such a stable interface:
 
    revision 1.15
    date: 2000/11/29 09:52:19;  author: simonb;  state: Exp;  lines: +90 -2
    Add a vm.uvmexp2 sysctl that uses a ABI-safe 'struct uvmexp_sysctl'.
 
 I don't know why this didn't keep the old number and ABI for the new
 sysctl (it's a little late now), but that's immaterial as the original
 submitter's bubblemon-dockapp was not compiled before 2000/11/29. The
 problem is that it's using an unsupported/unstable interface.
 
 Anyway, it looks as if the submitter provided a bubblemon package with
 a patch for this, so I think this PR can be closed... any objections?
 
 (Or maybe the unstable uvmexp interface should be removed so nothing
 else can trip on it?)
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost