> > Kurt, the problem for me is, that you constantly state that your approach is > the best. For me it is not. no userspace counterpart can handle transient conditions like kernel can... > > The major issue in your implementation is the lack of the possibility to > simulate several j1939 ECUs on one Linux host talking to each other via > virtual CAN busses to create a complete j1939 network. And so far you did not > address this request. Oliver, I tried to explain already several times that this stack _IS_ capable of having several j1939 ECU's on one linux host, talking to any CAN bus, virtual or physical. I agree that if this was not the case, your arguments would have been valid.
The major improvement (IMHO) of my in-kernel j1939 stack is that several applications can also contribute to the same ECU, without protocol violations. side note: this is not even a matter introduced with address claiming :-0 > ever done this? $ ip addr add 192.168.0.1/24 dev eth0 $ ip addr add 192.168.1.1/24 dev eth0 Likewise I do now: $ ip addr add j1939 0x20 dev can0 $ ip addr add j1939 0x21 dev can0 I see no problem there. With address claiming: $ ip addr add j1939 name 0123456789ABCDE0 dev can0 $ ip addr add j1939 name 0123456789ABCDE1 dev can0 and my daemon to choose addresses (posted later today on can-utils) $ jacd --range 0x20-0x30 0123456789ABCDE0 can0 $ jacd --range 0x20-0x30 0123456789ABCDE1 can0 No, no typos here. both ECU's will resolve conflicts on CAN, on the same host! The second will ECU will finally get 0x21, _as should be_ per J1939. Oliver, The way I understand your request, this addressed that. What did I miss up to here? I skipped a lot of your original email since the issue addressed here seems to be source of misunderstanding. Kind regards, Kurt _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
