On Wed, Feb 02, 2011 at 02:49:05PM +0100, Oliver Hartkopp wrote: > Your proposed structure is > > 2+4+8+4+1 = 19 > > Unfortunately this does not fit. I think the maximum size is 128. See: http://lxr.linux.no/#linux+v2.6.37/include/linux/socket.h#L11
> > Also the problem can not be solved to make struct sockaddr_can > longer than 14 bytes. E.g. if you build a CAN application with the > new sockaddr_can and then try to run this binary (16 byte struct) on > an older kernel expecting a 14 bytes (max 16 bytes) struct. :-( In the first patch, I solved that issue. > and putting the > > "/* 8 byte name when using dynamic addressing */" > > into a sockopt? That works for bind(), but what about connect(), getpeername(), getsockname(), recvfrom() & sendto() ? I consider that a workaround and therefore not good for new API design. > > +typedef __u64 name_t; > > Expect these kind of typedefs to be remarked as unwanted on the > netdev-ML. Typedefs may 'hide' things and therefore there are not > wanted. I had a longer discussion on this for the canid_t ... ok. > Btw. how dou you ensure the endian problem to be solved, when > working with __u64 bitfields? I prefer not carrying endianess problems into userspace. Really, as soon as it gets off the wire, I swap it. But that in [PATCH 2/3] which didn't get out by berlios. > > Regards, > Oliver Thanks, Kurt _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
