Subject: Re: VM_CMD() vs VM_CMD2()
To: Bang Jun-Young <junyoung@netbsd.org>
From: Matt Thomas <matt@3am-software.com>
List: tech-kern
Date: 08/21/2003 19:39:27
On Thursday, August 21, 2003, at 06:51 PM, Bang Jun-Young wrote:

> Hi,
>
> Could anyone shed light on why there are VM_CMD() and VM_CMD2() macros
> defined separately in sys/exec.h? VM_CMD() is just a VM_CMD2() with
> the last argument hardcoded 0 and doesn't seem to be very useful.

Because there are a lot of uses of NEW_VMCMD and only place the last 
argument is going to be non-zero is in the loading of the ELF 
interpreter.  So instead of changing all the instanses, adding a second 
a #define with the flag seemed reasonable.  See sonewconn/sonewconn1 as 
prior art.

> IMHO, it would be a bit easier to read sources if these were cleaned up
> as follows:
>
> Index: exec.h
> ===================================================================
> RCS file: /cvsroot/src/sys/sys/exec.h,v
> retrieving revision 1.100
> diff -u -r1.100 exec.h
> --- exec.h	2003/08/08 18:54:16	1.100
> +++ exec.h	2003/08/22 01:40:19
> @@ -251,14 +251,10 @@
>  void	new_vmcmd __P((struct exec_vmcmd_set *,
>  		    int (*) __P((struct proc *, struct exec_vmcmd *)),
>  		    u_long, u_long, struct vnode *, u_long, u_int, int));
> -#define	NEW_VMCMD(evsp,proc,len,addr,vp,offset,prot) \
> -	new_vmcmd(evsp,proc,len,addr,vp,offset,prot,0)
> -#define	NEW_VMCMD2(evsp,proc,len,addr,vp,offset,prot,flags) \
> +#define	NEW_VMCMD(evsp,proc,len,addr,vp,offset,prot,flags) \
>  	new_vmcmd(evsp,proc,len,addr,vp,offset,prot,flags)
>  #else	/* DEBUG */
> -#define	NEW_VMCMD(evsp,proc,len,addr,vp,offset,prot) \
> -	NEW_VMCMD2(evsp,proc,len,addr,vp,offset,prot,0)
> -#define	NEW_VMCMD2(evsp,proc,len,addr,vp,offset,prot,flags) do { \
> +#define	NEW_VMCMD(evsp,proc,len,addr,vp,offset,prot,flags) do { \
>  	struct exec_vmcmd *vcp; \
>  	if ((evsp)->evs_used >= (evsp)->evs_cnt) \
>  		vmcmdset_extend(evsp); \
>
> Note that I haven't started dealing with the relevant part in the C
> sources yet. ;-)
>
> What do you think?

I don't think it is.
-- 
Matt Thomas                     email: matt@3am-software.com
3am Software Foundry              www: 
http://3am-software.com/bio/matt/ Cupertino, CA              
disclaimer: I avow all knowledge of this message.