Kurt Van Dijck wrote:
> On Tue, Feb 09, 2010 at 06:03:30PM +0100, Oliver Hartkopp wrote:
>> AFAIK in J1939 you have broadcast announce messages (BAM) that send on two
>> different CAN identifiers in one direction. This could be handled within the
>> union.
> In fact, there's a lot more.
> J1939 introduces a network addressing (both source & destination).
> And this addressing tables (comparable to arp tables I think) should be
> kept in kernel.
> The CAN id's are then seperated into SRC & DST fields, and a PGN
> (iso11783 naming). SRC & DST is comparable to IP, in the way that is a
> mapped address from an 'ISONAME' (iso11783 naming). The PGN is roughly
> to be compared with a TCP port number, but again, roughly.
>
> So, J1939 much better matches the kernel-to-userspace API sendto,
> recvfrom, .... using all a 'struct sockaddr_xxx' derivate.
> I could use a seperate struct, but don't think that's an elegant
> solution.
>
> The transport protocol indeed used 2 'PGN's, but they are fixed. the
> transport protocol must thus be serialized, but that's a different
> thing.
Hi Kurt,
sorry for my late answer.
First of all i think the ISONAME is nothing that has to be handled inside
kernel context. What would be the benefit? ARP is also not implemented within
the TCP protocol socket :-)
Additionally you should use __u8, __u16, __u32 types.
My suggestion for a J1939 struct inside the can_addr union would be:
struct {
/* J1939 source device address */
__u8 srcaddr;
/* priority:3, reserve:1, datapage:1 */
__u8 ctrl;
/* Parameter Group Number (PGN) with dest addr / group extension */
__u16 pgn;
/* Secondary PGN for multiframe transmissions*/
__u16 pgnsec;
} j1939;
IMO we should leave as much information out of the kernel as possible.
E.g. the destination address is an integrated element of the PGN in connection
oriented J1939 communications.
Generally the address structure should only contain information that's really
needed to allow a usual communication requirement. Other things (like your
isoname that should not be relevant here anyway) or special settings that
differ from communication defaults could be set with sockopts.
What do you think?
Can you map your requirements to this reduced j1939 structure, or do you feel
there's something missing?
Regards,
Oliver
ps. The new j1939 struct is only 48 bits, which also fits perfectly into the
current union ;-)
>
>> What are your proposed new structure elements for a J1939 socketcan address?
> struct sockaddr_can {
> sa_family_t can_family;
> int can_ifindex;
> union {
> /* transport protocol class address information (e.g. ISOTP) */
> struct { canid_t rx_id, tx_id; } tp;
>
> /* J1939 address information */
> struct {
> /*
> * any of these parameters that are used in connect()
> * can be overruled by using sendto()
> */
> /* name: bind() sets source, connect sets dest */
> uint64_t name; /* bind != connect */
> /* pgn & priority: can be set by bind & connect */
> uint32_t pgn;
> uint8_t priority;
> /*
> * 'sa' is used in bind() & sendto(),
> * 'da' is used in connect() & sendto()
> */
> uint8_t sa; /* the originator address */
> uint8_t da; /* the destination address */
> } j1939;
>
> /* reserved for future CAN protocols address information */
> } can_addr;
> };
>
> this is my current working version.
>
> Now, this is a preliminary thing, and only for j1939/iso11783.
>
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
