[asterisk-bugs] [DAHDI-linux 0014499]: Ioctl defination in dahdi

Wed Mar 11 09:50:59 CDT 2009

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14499 
====================================================================== 
Reported By:                ys
Assigned To:                sruffell
====================================================================== 
Project:                    DAHDI-linux
Issue ID:                   14499
Category:                   dahdi (the module)
Reproducibility:            random
Severity:                   minor
Priority:                   normal
Status:                     confirmed
====================================================================== 
Date Submitted:             2009-02-18 09:01 CST
Last Modified:              2009-03-11 09:50 CDT
====================================================================== 
Summary:                    Ioctl  defination in dahdi
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...
====================================================================== 

---------------------------------------------------------------------- 
 (0101533) svnbot (reporter) - 2009-03-11 09:50
 http://bugs.digium.com/view.php?id=14499#c101533 
---------------------------------------------------------------------- 
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 http://bugs.digium.com/view.php?id=14499)
Reported by: ys
------------------------------------------------------------------------

http://svn.digium.com/view/dahdi?view=rev&revision=6124 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-11 09:50 svnbot         Checkin                                      
2009-03-11 09:50 svnbot         Note Added: 0101533                          
======================================================================