[asterisk-bugs] [DAHDI-linux 0014499]: Ioctl defination in dahdi
Asterisk Bug Tracker
noreply at bugs.digium.com
Wed Apr 29 12:20:42 CDT 2009
The following issue requires your FEEDBACK.
======================================================================
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: feedback
======================================================================
Date Submitted: 2009-02-18 09:01 CST
Last Modified: 2009-04-29 12:20 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...
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
2009-04-29 12:20 sruffell Status confirmed => feedback
======================================================================
More information about the asterisk-bugs
mailing list