gecko/media/webrtc/signaling/src/sipcc/cpr/linux/cpr_linux_ipc.c: In function 'msgsnd': gecko/media/webrtc/signaling/src/sipcc/cpr/linux/cpr_linux_ipc.c:58: error: '__NR_msgsnd' undeclared (first use in this function) gecko/media/webrtc/signaling/src/sipcc/cpr/linux/cpr_linux_ipc.c:58: error: (Each undeclared identifier is reported only once gecko/media/webrtc/signaling/src/sipcc/cpr/linux/cpr_linux_ipc.c:58: error: for each function it appears in.) gecko/media/webrtc/signaling/src/sipcc/cpr/linux/cpr_linux_ipc.c: In function 'msgrcv': gecko/media/webrtc/signaling/src/sipcc/cpr/linux/cpr_linux_ipc.c:63: error: '__NR_msgrcv' undeclared (first use in this function) gecko/media/webrtc/signaling/src/sipcc/cpr/linux/cpr_linux_ipc.c: In function 'msgctl': gecko/media/webrtc/signaling/src/sipcc/cpr/linux/cpr_linux_ipc.c:68: error: '__NR_msgctl' undeclared (first use in this function) gecko/media/webrtc/signaling/src/sipcc/cpr/linux/cpr_linux_ipc.c: In function 'msgget': gecko/media/webrtc/signaling/src/sipcc/cpr/linux/cpr_linux_ipc.c:73: error: '__NR_msgget' undeclared (first use in this function) gecko/media/webrtc/signaling/src/sipcc/cpr/linux/cpr_linux_ipc.c: In function 'cprCreateMessageQueue': gecko/media/webrtc/signaling/src/sipcc/cpr/linux/cpr_linux_ipc.c:273: warning: implicit declaration of function 'ftok'

There is no __NR_msg{get,snd,rcv,ctl} syscalls in i386. Instead, __NR_ipc handles all these calls with an additional ID. See: http://www.eglibc.org/cgi-bin/viewvc.cgi/trunk/libc/sysdeps/unix/sysv/linux/ipc_priv.h?view=markup http://www.eglibc.org/cgi-bin/viewvc.cgi/trunk/libc/sysdeps/unix/sysv/linux/i386/msgctl.c?view=markup http://www.eglibc.org/cgi-bin/viewvc.cgi/trunk/libc/sysdeps/unix/sysv/linux/msgget.c?view=markup http://www.eglibc.org/cgi-bin/viewvc.cgi/trunk/libc/sysdeps/unix/sysv/linux/msgrcv.c?view=markup http://www.eglibc.org/cgi-bin/viewvc.cgi/trunk/libc/sysdeps/unix/sysv/linux/msgsnd.c?view=markup

Comment on attachment 735164 [details] [diff] [review] patch Review of attachment 735164 [details] [diff] [review]: ----------------------------------------------------------------- Other than I don't know what the 5, 11 mean for __NR_ipc (which I don't see anywhere else in our tree; I'm guessing they're IPC channel identifiers), this seems reasonable. I advise someone who knows where __NR_ipc comes from should review that the calls are correct. From the webrtc side, this seems ok.

(In reply to Randell Jesup [:jesup] from comment #3) > Comment on attachment 735164 [details] [diff] [review] > Review of attachment 735164 [details] [diff] [review]: > ----------------------------------------------------------------- > Other than I don't know what the 5, 11 mean for __NR_ipc (which I don't see > anywhere else in our tree; I'm guessing they're IPC channel identifiers), > this seems reasonable. I advise someone who knows where __NR_ipc comes from > should review that the calls are correct. From the webrtc side, this seems > ok. 5 means there are 5 more parameters; 11, 12, 13, 14 are opcodes, eglibc defines them in ipc_priv.h. I should have done the same to make it more clear: #define IPCOP_msgsnd 11 #define IPCOP_msgrcv 12 #define IPCOP_msgget 13 #define IPCOP_msgctl 14

1) include Android system headers for constants and structs. 2) Removed magic number '5' for it's actually a redundent macro variable in eglibc 3) From the definition of struct ipc_perm defined in bionic/libc/kernel/common/linux/ipc.h[1], Android is using old ABI. So mask cmd parameter in msgctl explicitly. @dhylands, could you help review this patch? [1]: https://github.com/mozilla-b2g/platform_bionic/blob/ics-mr1-release/libc/kernel/common/linux/ipc.h#L19

Comment on attachment 736160 [details] [diff] [review] v2 Review of attachment 736160 [details] [diff] [review]: ----------------------------------------------------------------- Although I have to ask the bigger question. Why aren't we using the same IPC mechanisms used in say gecko for communicating between the child and parent processes?

(In reply to Dave Hylands [:dhylands] from comment #6) > Although I have to ask the bigger question. Why aren't we using the same IPC > mechanisms used in say gecko for communicating between the child and parent > processes? Have no idea here. Just fix compile errors for emulator-x86 build :(

Add r= only