From owner-cvs-usrbin  Sat Dec 13 02:31:31 1997
Return-Path: <owner-cvs-usrbin>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id CAA11838
          for cvs-usrbin-outgoing; Sat, 13 Dec 1997 02:31:31 -0800 (PST)
          (envelope-from owner-cvs-usrbin)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA11806;
          Sat, 13 Dec 1997 02:31:20 -0800 (PST)
          (envelope-from bde@zeta.org.au)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id VAA30123; Sat, 13 Dec 1997 21:27:44 +1100
Date: Sat, 13 Dec 1997 21:27:44 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199712131027.VAA30123@godzilla.zeta.org.au>
To: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-sys@FreeBSD.ORG,
        cvs-usrbin@FreeBSD.ORG, cvs-usrsbin@FreeBSD.ORG, sef@FreeBSD.ORG
Subject: Re: cvs commit: src/sys/sys pioctl.h src/sys/miscfs/procfs procfs_vnops.c src/usr.bin/truss main.c setup.c src/usr.sbin/procctl procctl.c
Sender: owner-cvs-usrbin@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>  Modified files:
>    sys/sys              pioctl.h 
>    sys/miscfs/procfs    procfs_vnops.c 
>    usr.bin/truss        main.c setup.c 
>    usr.sbin/procctl     procctl.c 
>  Log:
>  Change the ioctls for procfs around a bit; in particular, whever possible,
>  change from
>  
>  	ioctl(fd, PIOC<foo>, &i);
>  
>  to
>  
>  	ioctl(fd, PIOC<foo>, i);
>  
>  This is going from the _IOW to _IO ioctl macro.  The kernel, procctl, and
>  truss must be in synch for it all to work (not doing so will get errors about
>  inappropriate ioctl's, fortunately).  Hopefully I didn't forget anything :).

This is a regression.  _IO is for ioctls that don't take any args after the
request number.  From <sys/iocom.h>:

	#define	IOC_VOID	0x20000000	/* no parameters */
	...
	#define	_IOC(inout,group,num,len) \
		(inout | ((len & IOCPARM_MASK) << 16) | ((group) << 8) | (num))
	#define	_IO(g,n)	_IOC(IOC_VOID,	(g), (n), 0)

There is compatibility cruft in in sys_generic.c that results in one bogus
varadic arg of type caddr_t being supported, provided certain undefined
and implementation-defined behaviour is benign.  A bogus varadic arg of
type int can work too.  Even correct application code that doesn't pass
an extra arg can work :-).  Don't depend on this in new interfaces.

Bruce