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

[Asterisk Bug Tracker]

The following issue has been UPDATED. 
====================================================================== 
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:                     closed
Resolution:                 fixed
Fixed in Version:           2.2.0-rc2
====================================================================== 
Date Submitted:             2009-02-18 09:01 CST
Last Modified:              2009-05-04 09:21 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...
====================================================================== 

---------------------------------------------------------------------- 
 (0104089) sruffell (administrator) - 2009-05-04 09:21
 http://bugs.digium.com/view.php?id=14499#c104089 
---------------------------------------------------------------------- 
I'm going to close this.  Please reopen if the ioctl numberings still cause
problems for you on FreeBSD. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-05-04 09:21 sruffell       Note Added: 0104089                          
2009-05-04 09:21 sruffell       Status                   feedback => resolved
2009-05-04 09:21 sruffell       Fixed in Version          => 2.2.0-rc2       
2009-05-04 09:21 sruffell       Resolution               open => fixed       
2009-05-04 09:21 sruffell       Status                   resolved => closed  
======================================================================