Oliver, Your comments are very 'diverse'. I addressed a subset in this reply.
On Wed, Feb 09, 2011 at 08:31:06PM +0100, Oliver Hartkopp wrote: > On 03.02.2011 10:39, Kurt Van Dijck wrote: > > This contains the j1939 documentation. > > > > > + The j1939 sockets operate on CAN network devices (see SocketCAN). Any > > j1939 > > + userspace library operating on CAN raw sockets will still operate > > properly. > > + Since such library does not communicate with the in-kernel > > implementation, > > + care must be taken that these 2 do not interfere. In practice, this means > > + they cannot share ECU addresses. A single ECU (or virtual ECU) address is > > + used by the library exclusively, or by the in-kernel system exclusively. > > I'm really concerned, that there's no possibility to have more than one ECU > running on our multi-user system ... > > If that would be possible, some kind of 'ecu' entry would need to be part of > the sockaddr_can, right? > hold on: multiple ECU's are possible. It was a key feature of the design. The 'ecu' entry of the sockaddr_can is in fact the 'u8 addr', since that identifies the ecu (in case of static addressing ...). What I wanted to say here is that when you start issuing j1939 CAN frames from the same host, the local j1939 stack will not recognize those j1939 frames as local, and therefore, the SA must differ. In other words, you can't mix j1939 stacks and expect them to cooperate! > > + > > + In order to send data, a bind(2) must have succeeded. bind(2) assigns a > > local > > + address to a socket. For this to succeed, you can only choose addresses > > + that have been assigned with '$ ip addr add j1939 .... dev canX'. > > When implementing only one ECU on the host. > > Now that i have read several documentation and also some j1939 API references > like > > http://www.esd-electronics-usa.com/Shared/Handbooks/CAN-J1939StackManual.pdf > > i'm really sure that i definitely want to have more than one ECU at a time on > my host (e.g. for rest-bus-simulation) and that binding j1939 addresses to > network interfaces is broken. you can bind multiple addresses on an interface, so there is no problem. > > > + When an > > + empty address is assigned (ie. SA=0xff && name=0), a default is taken for > > + the device that is bound to. > > As you stated somewhere above at "2. Motivation *addressing" only one process > should need to keep track of setting the relevant addresses for a specific > ECU. Once the ECU is part of struct sockaddr_can this can be managed. All > processes can use the ECU-specific address information at least one of the ECU > member processes has defined. > > Please keep off attaching j1939 addresses to network devices. But aren't you suggesting the same thing but call it 'ecu' instead of 'address'? > > > In general i wonder if it would make sense to define > > struct { > __u32 pgn; > __u8 prio; > __u8 src; > __u8 dest: > __u8 ecu; > } j1939; > 1) you mix src & dst in 1 structure. 2) what is 'ecu'? Isn't that the source address, indicated by 'src'? > As it makes *really* clear in any case - also when using sento() and > recvfrom() - what the j1939 stack does. > > Even when it's a nice idea to handle all the address claiming infrastructure > inside the kernel: It's the only option to make the stack _fully_ compliant since address claiming requires other traffic to suspend momentarily. > > 1. It's not mandatory I do not require it neither. > > 2. Things that could be handled outside the kernel should be handled outside > the kernel. There are several userspace j1939 implementations doing so. Note that only the _absolutely required_ part is put in kernel. No address claiming traffic is sent from kernelspace. It _must_ come from userspace. > > 3. The concepts with ECUs, segments and data structures are really complex and > hard to understand and to review. That is true, but I cannot introduce protocol violations for that reason. > > If you insist on address claiming in kernelspace you might override the given > src and dst adresses with a sockopt When using address claiming, then the name is the unique identification of an ECU, not its SA. So, they're not options. > > SO_J1939_DEST_NAME > SO_J1939_SRC_NAME > > so that these name resolved values are used on this specific bound/connected > socket instead of the given __u8 values - as an _option_. > > > > + can_addr.j1939.pgn specifies the PGN (max 0x3ffff). Individual bits are > > + specified above. > > + > > + can_addr.j1939.name contains the 64-bit J1939 NAME. > > + > > + can_addr.j1939.addr contains the source address. > > + > > + When sending data, the source address is applied as follows: If > > + can_addr.j1939.name != 0 the NAME is looked up by the kernel and the > > + corresponding Source Address is used. If can_addr.j1939.name == 0, > > + can_addr.j1939.addr is used. > > You provide two addressing schemata in one structure here. They can mix: send from fixed SA to dynamic SA(dst) > > > + If no-one else contest the address claim within 250ms after > > transmission, the > > + kernel marks the NAME-SA assignment as valid. The valid assignment will > > be > > + kept, among other valid NAME-SA assignments. From that point, any socket > > + bound to the NAME can send packets. > > + > > + If another ECU claims the address, the kernel will mark the NAME-SA > > expired. > > + No socket bound to the NAME can send packets (other than address claims). > > + To claim another address, some socket bound to NAME, must bind(2) again, > > + but with only j1939.addr changed to the new SA, and must then send a > > + valid address claim packet. This restarts the state machine in the kernel > > + (and any other participant on the bus) for this NAME. > > This is the complexity i would prefer to leave out of the kernel ... And move this complexity to each individual user, with potential race conditions? > > > > + > > +5.7 SO_J1939_DEST_MASK > > + > > + When a destination is specified by its name (and thus using dynamic > > addressing), > > + and such name should be unique amongst the world, it may be hard to > > predict the > > + name of eg. a gearbox controller on the bus, although its type and > > manufacturer > > + are know. This is because the serial number is part of the name. > > + To simplify specifying a destination, a per-socket destination mask is > > provided > > + that is activated whenever a destination name is wanted. Any bits > > cleared in > > + this mask are ignored during the lookup. As a result, more than 1 ECU > > may match > > + this name/mask pair. In all cases, the first match is used. > > + The API is thus capable of specifying a name for eg. the gearbox > > controller, > > + without knowing its serial number. > > Yes. The address claiming and name handling inside the kernel is a heavy > thing. > I just thought (from experience) that this would be handy. > > +6. /proc Interface. > > +-------------------------------- > > + > > + > > + Files giving you a view on the in-kernel operation of J1939 are located > > at: > > + /proc/net/j1939. > > + > > +6.1 /proc/net/j1939/ecu > > + > > + This file gives an overview of the known ECU's to the kernel. > > + - iface : network interface they operate on. > > + - SA : current address. > > + - name : 64bit NAME > > + - flags : 'L' = local, 'R' = remote > > + > > Ah, you have ECUs - can you have more that one ECU marked as 'L'ocal? yes yes yes. > > > > The lack of multiple ECU > support on a single host (coming hand-in-hand with addresses attached to > network interfaces) needs some rework. There is not reason on a multi-user > system to stay away from a multi-ECU support that's implemnted in userspace > j1939 stacks (as referenced above). I tried to explain the thing here. It is capable, but somehow, I seem incapable of showing that... > Kurt _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
