Oliver,
I resumed work on a j1939 implementation. I got stuck in modifying iproute2
since j1939 implies an addressing concept.
If I were to create a netlink interface that allows me to:
$ ip -f j1939 addr add 0x90 dev can0,
I would have registered j1939 address operations in a seperate af_family.
If I have j1939 a member of AF_CAN, the netlink routines inside the kernel
come into net/can/af_can.c(?) and need extra code to reach j1939 specific code.
I currently have:
rtnl_register(PF_CAN, RTM_NEWADDR, j1939rtnl_newaddr, NULL);
rtnl_register(PF_CAN, RTM_DELADDR, j1939rtnl_deladdr, NULL);
rtnl_register(PF_CAN, RTM_GETADDR, NULL, j1939rtnl_dump_ifaddr);
which feels a bit wrong.
Not sure if I was able to explain my dilemma right ...
Do you have any suggestions?
Kurt
On Sat, Feb 27, 2010 at 07:37:56PM +0100, Oliver Hartkopp wrote:
> Kurt Van Dijck wrote:
> > On Fri, Feb 26, 2010 at 12:15:35PM +0100, Kurt Van Dijck wrote:
> >
> IMO creating a PF_J1939 goes far beyond the users needs. As you know usually
> J1939 implementations are completely running in userspace ... and people are
> also happy with that.
>
> J1939 is 'just one definition' of what you can do with CAN frames. Therefore
> putting some of it's (timecritical & segmenting) functionalities inside the
> kernel in a new protocol inside PF_CAN is the appropriate way, IMO.
>
> Regards,
> Oliver
>
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
