On 21.01.2011 16:20, Kurt Van Dijck wrote: > On Fri, Jan 21, 2011 at 03:49:54PM +0100, Oliver Hartkopp wrote: >> 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 ... > so: > $ ip -f can addr add j1939 0x90 dev can0 .... > > That is ok as well
Yes, that looks good. >> >> >> 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? > well, you had indeed the same problem as I do. 8-> >> >> So far you would be the only user to add an additional address via netlink. > so far yes. But desinging an API that only works when I'm the only user is > guaranteed > to have problems sooner or later... >> >> 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. > I do think this would be a good solution, but I feel a bit incapable. I'm not > experienced in netlink ... Me too. It took two days until i really managed to drill a hole from userspace to my gw.c code :-)) Btw. if we'd like to support RTM_???ADDR for different CAN protocols e.g. the three callbacks could be registered by adding a pointer (to three pointers) in struct can_proto (see include/linux/can/core.h). I'll take a look on this if there are similar implementations in the networking code ... Regards, Oliver _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
