Kurt Van Dijck wrote: > On Fri, Feb 26, 2010 at 10:50:00AM +0100, Oliver Hartkopp wrote:
>>> To make the API easier, I'd think it's usefull to have the kernel take >>> the first 'local address assigned' when local address is missing at the >>> time of send. >>> IMO, bind() should not be necessary for receiving too. >> You should probably use the special SA/DA values to indicate broadcast >> addresses. > I'm not sure I understand. > Do you mean: use 0xff as SA to indicate to the kernel to take the > default? that is how I implemented now. Yes. That was my intention. >> But virtual ECUs distinguish from SA, right? > yep. >> Then it's not 'visible' in the concept. > ?? > [...] I just wanted to say, that from the protocols view it is not relevant whether an ECU ( == a CAN node) implements one or more ECUs. >>>>>> At the next level, j1939 describes a dynamic addressing scheme (the >>>>>> above is working fine with static addresses only). That's especially >>>>>> used a lot in agriculture (our main market). >>>>>> At that point, SA & DA are not persistent anymore, but the 8byte name >>>>>> is. >>>>>> We intent not to let kernel code participate in this dynamic >>>>>> addressing, >>>>>> but let the kernel code follow the actions on the bus. Since a single >>>>>> instance must decide which name an SA belongs to & vice versa, the >>>>>> kernel is the perfect place. >>>> No. >>>> >>>> I checked the idea of the Dynamic Address Configuration in SAE J1939 here >>>> >>>> http://www.can-wiki.info/SaeJ1939 >>>> >>>> and this is definitely something that has to be handled outside the kernel. >>> Like I mentioned, the actions are taken in userspace, but the kernel >>> should track when a SA is valid and when not. >> And when it's not - what happens? > good question. > when dynamic addressing is used, then during the address claim 'dead > time' the j1939 spec says it's illegal to send other stuff with that SA. > So, if such packet comes in, it _should_ be dropped/ignored. Ah, i see. >> Is the socket collapsing after sending a socket error? > collapsing? I don't understand the word. E.g. some sockets are set in an unusable state, when an error occurred on it's specific transport protocol. E.g. the userspace app get's a socket error on a socket (e.g. -ETIMEO(ut)) and then you need to close this socket and create a new one, if you still want to communicate ... >> So far i cannot see a value in putting the name into the kernel. When the > 2 packets from the same ECU may arrive. a regular socket user must be > able to recognize them as coming from the same ECU. > therefore, instead of relying on the SA, in dynamic addressing > environments, such user should rely on the name. > sending a packet to a particular ECU has the same issue. the same SA > does not necessarily address the same ECU. > To avoid delay problems, the mapping name->SA is done in kernel, in a > very late stage. But the kernel needs the names then. Ok - comment follows. >> Finally (even if i do not like it) a socketoption containing the 64 bit name >> can be placed into the socket as soon as it is created. Before or after >> bind() >> is irrelevant. > for outgoing packets, that could be done. > and for incoming, one could create an extra ioctl. > but, it deviates from existing API's in a way I don't like. > Such API would suggest the SA in the sockaddr is reliable, which is not > always the case. To know that, an extra getsockopt or ioctl is needed. > bind(), connect(), recvfrom() & sendto() all benefit from a proper > sockaddr _with_ the 64bit name. Commented later. > I feel that apart from dynamic addressing, we pretty much agree on > everything :-). Yep :-) > May I state this ?: > Doing proper dynamic addressing across several sockets/processes needs a > limited kernel knowledge. I don't contest the kernel's effort should be > minimal. Without kernel support, there are some mistakes that cannot be > avoided (and those mistakes are common, I can assure you). To let the > kernel do it's minimal action, userspace communication must be done with > 64bit names instead of 8bit addr. > Whether or not the 64bit name is added in the sockaddr decides on being > capable to do proper dynamic addressing, or leaving transient problems > in it's dynamic characteristic. Thanks for all you explanation. Indeed the 64 bit 'name' seems to be a vital knowledge to ensure a proper dynamic address handling (& recovery). Btw. dynamic addressing is not an *essential* functionality for all J1939 applications, that only like to communicate using J1939 protocols, right? Having struct { uint8_t sa, da; uint8_t priority; uint32_t pgn; } j1939; and uint64_t name; in /one/ structure IMO could lead to confusion and therefore to potential misusage. I would suggest to have the shown j1939 struct in sockaddr_can to handle the J1939 communication without dynamic addressing. By setting the uint64_t name with a socketoption the behaviour of the selected socket changes in the way that ... - the source address (sa) is set dynamically depending on the name - the sockets data structures are updated according the dynamic addressing - any other things that differ when using the J1939 name Would this work for you? Regards, Oliver _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
