On 21.01.2011 14:39, Kurt Van Dijck wrote: > 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.
I think this would still be part of AF_CAN ... > 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. Currently af_can.c has not registered any rtnl stuff. > 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. The only problem here is that you grab the whole class of RTM_???ADDR and use it for j1939 - see suggestion below. > Not sure if I was able to explain my dilemma right ... > > Do you have any suggestions? You might take a look into socketcan/trunk/kernel/2.6/net/can/gw.c and can-utils/cangw.c I also had a similar problem to connect the userspace tool 'cangw' with the gw.c in the kernelspace. Can the netlink interface to the can-gw be used as an example for your problem? So far you would be the only user to add an additional address via netlink. I don't know if there's another use-case in the future that would require RTM_???ADDR ... if so we should think about some kind of infrastructure that can handle these RTM_???ADDR functions for different protocols inside the protocol family PF_CAN. E.g. define a NLMSG struct with the protocol identifier (like CAN_RAW. CAN_BCM, ... see can.h) being the first element. Regards, Oliver _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
