Summary:	DAHLIN-00081: Ioctl defination in dahdi
Reporter:	Yuri (ys)	Labels:
Date Opened:	2009-02-18 09:01:44.000-0600	Date Closed:	2009-09-21 09:50:43
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	dahdi (the module)
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	I now play with porting dahdi to other OS (for example FreeBSD, at least, for timing). I found, that some ioctl call macro defined not as its expected. May be, at this moment, in linux this check not so strict, but in future, and in other OS'es this _IO[WR] macro defines, whether it is necessary to map user data to kernel space and back. And, if, for example, ioctl command defined as _IOR, data from user space not reached the driver and for _IOW - kernel driver can't change data in user space. For example: #define DAHDI_GET_PARAMS _IOR(DAHDI_CODE, 5, struct dahdi_params) #define DAHDI_GETCONF _IOR(DAHDI_CODE, 12, struct dahdi_confinfo) This ioctl's read channel number from user space (stack.param.channo or stack.conf.chan) and return channel or conference parameters to users space, so, it must be defined as _IOWR? #define DAHDI_SETCONF _IOW(DAHDI_CODE, 12, struct dahdi_confinfo) This ioctl SET conference pseudo channel number and return it number in stack.conf to user space, so, also be defined as _IOWR.. #define DAHDI_CONFDIAG _IOR(DAHDI_CODE, 15, int) #define DAHDI_CHANDIAG _IOR(DAHDI_CODE, 44, int) This diagnostic ioctl call don't send anything to user space, only read conference or channel number from there. And must be _IOW. #define DAHDI_GETGAINS _IOR(DAHDI_CODE, 16, struct dahdi_gains) In call to this, channel number also passed from user space, and gains returned back to user. This also be _IOWR. Also, in this ioctl command: DAHDI_SETGAINS, DAHDI_GETTONEZONE, DAHDI_GET_BUFINFO, DAHDI_SET_DIALPARAMS, DAHDI_GETRXBITS, DAHDI_GETSIGFREEZE I think, that ioctl type should be unique in sequence. but for each different ioctl operation, types should be sequentially assigned numbers (Without duplicates). Main trouble: this changes affect dahdi-tools and some asterisk modules: chan_dahdi, app_meetme, etc.. And after this changes all these need to be recompiled...
Comments:	By: Digium Subversion (svnbot) 2009-03-11 09:50:59 Repository: dahdi Revision: 6124 U   linux/trunk/drivers/dahdi/dahdi-base.c U   linux/trunk/include/dahdi/user.h ------------------------------------------------------------------------ r6124 | sruffell | 2009-03-11 09:50:59 -0500 (Wed, 11 Mar 2009) | 4 lines Fix direction bits on several ioctls. (related to issue DAHLIN-81) Reported by: ys ------------------------------------------------------------------------ http://svn.digium.com/view/dahdi?view=rev&revision=6124 By: Shaun Ruffell (sruffell) 2009-03-11 10:39:19 Ys, looking at this comment: "Also, in this ioctl command: DAHDI_SETGAINS, DAHDI_GETTONEZONE, DAHDI_GET_BUFINFO, DAHDI_SET_DIALPARAMS, DAHDI_GETRXBITS, DAHDI_GETSIGFREEZE I think, that ioctl type should be unique in sequence. but for each different ioctl operation, types should be sequentially assigned numbers (Without duplicates)." It is unclear if this also causes problems on BSD for you. By: Shaun Ruffell (sruffell) 2009-05-04 09:21:00 I'm going to close this.  Please reopen if the ioctl numberings still cause problems for you on FreeBSD.