**** BEGIN LOGGING AT Mon Nov 09 02:59:56 2009
Nov 09 07:51:29 <Spider-Pork> morning
Nov 09 17:06:28 <denkenz> holtmann: Review the netlink patch, that one's up your alley
Nov 09 17:29:40 <holtmann> denkenz: That stuff has to go to netdev first. It touches kernel headers.
Nov 09 17:30:05 <denkenz> holtmann: Well primarily it touches ones in ofono tree
Nov 09 17:30:18 <denkenz> which are a copy
Nov 09 17:31:22 <denkenz> Anyway, the patch is actually OK
Nov 09 17:31:31 <denkenz> Of course I'd just rather #pragma all of this stuff out
Nov 09 17:32:43 <holtmann> Problem with these things are that there are CPU out there where it is different. And the network guys normally do know what works and what actually breaks.
Nov 09 17:33:04 <holtmann> We could also have an ABI issues here. So preferred mailing list is netdev for this stuff.
Nov 09 17:33:16 <denkenz> agreed, but your compiler flags are borking the kernel headers
Nov 09 17:33:39 <denkenz> so we either need to fix it or turn off the warnings
Nov 09 17:34:22 <holtmann> Yeah. Personally I thing the kernel headers of netlink are pure evil crap. And whoever did them, was smoking something really nice.
Nov 09 17:34:25 <courmisch> in sockaddr case, this does not even make sense. The pointer will be used for memory copy from/to kernel space, so there cannot be alignment issues
Nov 09 17:34:50 <holtmann> However we can just turn of the compiler errors here if that is what it takes.
Nov 09 17:35:08 <holtmann> What is the problem with sockaddr btw. that we are trying to fix here?
Nov 09 17:35:09 <courmisch> IMHO, cast-align is not meant as a by-default warning
Nov 09 17:35:26 <courmisch> GCC thinks sockaddr_pn alignment is lower than sockaddr
Nov 09 17:35:32 <courmisch> so caboom in sendto and recvfrom
Nov 09 17:35:58 <holtmann> Where in the code? Give me a line.
Nov 09 17:36:26 <courmisch> I don't have the code here
Nov 09 17:36:39 <courmisch> on ARM, this happens wherever you call sendto or recvfrom
Nov 09 17:36:46 <courmisch> I had the same problem with sockaddr_in even
Nov 09 17:36:49 <denkenz> gisi/socket.c
Nov 09 17:36:59 <denkenz> line 90 or so
Nov 09 17:37:37 <denkenz> Any time any specific sockaddr_foo is cast to sockaddr the warning is issued
Nov 09 17:38:03 <denkenz> probably because sockaddr is an anonymous struct
Nov 09 17:38:35 <holtmann> Is it really sockaddr_pn causing this issue or just the __pad stuff?`
Nov 09 17:39:20 <courmisch> sockaddr is not anymous
Nov 09 17:39:27 <courmisch> it's defined in ssys/socket.h
Nov 09 17:39:51 <courmisch> sockaddr_* -> sockaddr causes this
Nov 09 17:40:13 <holtmann> Why is the Phonet stuff misbehaving and in BlueZ we never saw that problem?
Nov 09 17:40:59 <courmisch> does BlueZ have a 32-bits field?
Nov 09 17:41:14 <courmisch> did you ever build BlueZ on ARM with cast-align
Nov 09 17:41:30 <holtmann> Yes. We use the same compiler warning as for oFono and ConnMan.
Nov 09 17:41:38 <holtmann> struct sockaddr_l2 {
Nov 09 17:41:38 <holtmann> 	sa_family_t	l2_family;
Nov 09 17:41:38 <holtmann> 	unsigned short	l2_psm;
Nov 09 17:41:38 <holtmann> 	bdaddr_t	l2_bdaddr;
Nov 09 17:41:40 <holtmann> 	unsigned short	l2_cid;
Nov 09 17:41:42 <holtmann> };
Nov 09 17:41:43 <courmisch> I have the same problem in VLC casting sockaddr_storage to sockaddr
Nov 09 17:41:44 <holtmann> This is one of them.
Nov 09 17:42:54 <holtmann> jhe: Do you have compiler warning when building BlueZ for the N900?
Nov 09 17:51:48 <denkenz> Well cross compiling using the openmoko toolchain I get no warnings on BlueZ or oFono
Nov 09 17:56:48 <denkenz> holtmann: Also Martin's patch 3/4
Nov 09 17:57:20 <denkenz> holtmann: Should we pass a custom struct there for data that holds interface/chat
Nov 09 17:57:36 <denkenz> holtmann: Or make __ofono_atom_get_modem public API?
Nov 09 18:07:25 <courmisch> maybe some CS GCC 4.2 bug then
Nov 09 18:42:07 <holtmann> denkenz: Not sure actually.
Nov 09 19:26:50 <jhe> holtmann: nope, at least nothing related to alignment
Nov 09 20:46:43 <balrog-k1n> whoah, Qualcomm modem sent a \r\n+CMTI: "ME",-1\r\n
Nov 09 21:04:34 <denkenz> nice :)
Nov 09 21:42:09 <dilinger> heh
**** ENDING LOGGING AT Tue Nov 10 02:59:57 2009