On Sat, Feb 13, 2010 at 05:32:52PM +0100, Oliver Hartkopp wrote:
> 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.
I'll be off for a week too :-)
>
> 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.
I thought the C99 types are fixed-size enough, and they are portable,
and as such have preference above the pre-C99 types. I should refer to
a document here, but can't find it anymore.
>
> 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?
No, I feel there's a lot missing.
And talking without the real implementation known is bit weird.
>
> Regards,
> Oliver
Kurt
>
> ps. The new j1939 struct is only 48 bits, which also fits perfectly into the
> current union ;-)
I got that picture.
>
> >
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
