On Fri, Jan 16, 2015 at 12:39 AM, Dmitry V. Levin <[email protected]> wrote: > On Thu, Jan 15, 2015 at 12:03:20PM -0800, enh wrote: >> is there anything we can do about the SND* mess? the most common >> conflict i see on Android is the same one i see on my desktop: >> >> ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or >> TCGETS, {B38400 opost isig icanon echo ...}) = 0 >> >> Android does use _some_ of the SND* ioctls, so i don't want to just >> hack them all out of our strace. > > strace uses only 16 bits (8-bit number and 8-bit type) of the 32-bit ioctl > command, so the only real solution to this issue is to take into account > remaining 16 bits (size and direction). > > For example, > SNDCTL_TMR_TIMEBASE is _IOC(_IOC_READ|_IOC_WRITE, 'T', 1, sizeof(int)), > SNDRV_TIMER_IOCTL_NEXT_DEVICE is _IOC(_IOC_READ|_IOC_WRITE, 'T', 1, > sizeof(struct snd_timer_id)), > TCGETS is architecture-specific, its generic value 0x5401 is _IOC(0, 'T', 1, > 0). > > As you can see all these 32-bit values are different. > The only question is how to evaluate these remaining bits reliably, especially > 14 bits (or 13 on alpha, mips, powerpc, and sparc) of ioctl command size.
Or we could do that, yes. I don't know why I have occulted this solution. I have missed the 14/13 bit snafu though. Maybe we can create 2 ioctlent.h.in files, 1 for the 14 bits size, and another one for the 13 bits one and compile the right one for each arch. -- Gabriel Laskar ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ Strace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/strace-devel
