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

[Asterisk Bug Tracker]

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 10:39 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...
====================================================================== 

---------------------------------------------------------------------- 
 (0101537) sruffell (administrator) - 2009-03-11 10:39
 http://bugs.digium.com/view.php?id=14499#c101537 
---------------------------------------------------------------------- 
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. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-11 10:39 sruffell       Note Added: 0101537                          
======================================================================