Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 18 Jan 2003 09:20:31 -0500
From:      Hiten Pandya <hiten@unixdaemons.com>
To:        Scott Long <scott_long@btc.adaptec.com>
Cc:        Craig Rodrigues <rodrigc@attbi.com>, Will Andrews <will@csociety.org>, Joe Marcus Clarke <marcus@marcuscom.com>, freebsd-current@FreeBSD.ORG, dillon@FreeBSD.ORG, hiten@unixdaemons.org
Subject:   Re: VM_METER no longer defined?
Message-ID:  <20030118142031.GA96568@unixdaemons.com>
In-Reply-To: <3E28943E.3000702@btc.adaptec.com>
References:  <XFMail.20030117052330.conrads@cox.net> <3E284083.3030504@btc.adaptec.com> <1042826526.328.24.camel@gyros> <20030117182610.GR30015@procyon.firepipe.net> <20030117232821.GA5237@attbi.com> <3E28943E.3000702@btc.adaptec.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 17, 2003 at 04:39:42PM -0700, Scott Long wrote the words in effect of:
> Craig Rodrigues wrote:
> 
> >On Fri, Jan 17, 2003 at 10:26:10AM -0800, Will Andrews wrote:
> >
> >>Of course, these things can be fixed.  But I consider this change
> >>gratuitous and it breaks standard compatability rules: deprecate
> >>for one major version and remove in the second.  I haven't seen
> >>any reason why this couldn't be added to vm/vm_param.h:
> >>
> >>#define VM_METER VM_TOTAL
> >>
> >>for compatability purposes.  This change is way too sudden in an
> >>external API (if it's supposed to be internal, then protect it
> >>with an #ifdef _KERNEL already!).
> >
> >
> >How about this then:
> >
> >
> >Index: vm_param.h
> >===================================================================
> >RCS file: /home/ncvs/src/sys/vm/vm_param.h,v
> >retrieving revision 1.16
> >diff -u -r1.16 vm_param.h
> >--- vm_param.h	2003/01/11 07:29:46	1.16
> >+++ vm_param.h	2003/01/17 23:25:52
> >@@ -89,6 +89,8 @@
> > #define VM_SWAPPING_ENABLED	11	/* swapping enabled */
> > #define	VM_MAXID		12	/* number of valid vm ids */
> >
> >+#define VM_METER	VM_TOTAL /* backwards compatibility, struct vmmeter 
> >*/
> >+
> > #define CTL_VM_NAMES { \
> > 	{ 0, 0 }, \
> > 	{ "vmtotal", CTLTYPE_STRUCT }, \
> >
> >
> >
> >
> >
> >The only place where VM_METER is used in this directory was in vm_meter.c:
> >
> >    240 SYSCTL_PROC(_vm, VM_METER, vmmeter, CTLTYPE_OPAQUE|CTLFLAG_RD,
> >    241     0, sizeof(struct vmtotal), vmtotal, "S,vmtotal",
> >    242     "System virtual memory statistics");
> >
> >This changed to:
> >
> >    240 SYSCTL_PROC(_vm, VM_TOTAL, vmtotal, CTLTYPE_OPAQUE|CTLFLAG_RD,
> >    241     0, sizeof(struct vmtotal), vmtotal, "S,vmtotal",
> >    242     "System virtual memory statistics");
> >
> >
> >
> This is ugly and only further perpetuates what appears to be a 
> gratuitous API
> change.  Let's wait to hear from the submitter (Hiten) and committer 
> (Matt) to
> see why this was needed in the first place.
> 
> Hiten?  Matt?

The change was made, because VM_METER was a bogus name for what it did.
It returned struct vmtotal, but we named it VM_METER.  Infact, I tried
to push this change some long time ago, but there were complications
(people busy etc...).

I think applicatins to should be changed to use VM_TOTAL, instead of
VM_METER, because that's the correct name.  This is the same issue with
the KMEM_METER define, which will be resolved once I get around to it.

I sent this change to Matt first, to check if it was right, since he is
the VM guru and whatnot.  Also, the change was made quite a while ago.
Before we entered the freeze, IIRC.  IMHO, backing it out will just make
more and more apps use it, and it will be totally sad -- but hey, I am
not Release Engineer, so final decision is up to you.

Cheers.

P.S. Apologies for taking long to reply, I was out party-ing. :^)

--
Hiten Pandya (hiten@unixdaemons.com, hiten@uk.FreeBSD.org)
http://www.unixdaemons.com/~hiten/

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030118142031.GA96568>