Hi all, > Robert Schwebel wrote: > > ... > > In december, we have made a synchronisation meeting with the VW people > > who made the initial port for 2.4; they are more focussed on having > > higher level transport protocols ontop of the "raw" socket interface we > > currently use. During that process we have reviewed the user interface > > with regard to their use cases, so it will have to be changed a little > > bit before we have something which is in a state to be posted on lkml. > >
To be more correctly: Our focus is more on content-filtering of cyclic sent and received CAN-messages as well as on CAN-transport-protocols like ISO-TP (where two CAN-IDs are used to implement a point-to-point connection via the CAN-Bus by segmenting long (means >8 Byte) PDUs). The transport protocols and the so called "Broadcast-Manager" (for content-filtering, cyclic sending, RTR-Handling, Timeout-Handling) are not ontop the RAW-socket but arranged /next/ to the CAN_RAW-protocol in the protocol-family PF_CAN. You may find a picture of this 'arrangement' in the first hit of 'PF_CAN' in google (sorry it's german - figure page 5): http://www.network-on-wheels.de/downloads/VDE2004_Luebke_Paper.pdf As we had some problems to publish our software, we shared our ideas with Robert, Jan and Benedikt who have been working on the same problems in 2004. We are now bringing our implementations and APIs together, to publish a real Kernel-proof implementation for PF_CAN. Fortunately our implementations do not differ in core-things so it's just a bit cosmetic on both sides. Btw. VW has a Kernel 2.4 implementation and Robert and Benedikt have a Kernel 2.6 port - so it becomes a win-win-situation for both sides ... :-) > Jan Kiszka wrote: > > Beyond the outstanding comparably minor API adjustments, we furthermore > discussed first ideas how to define the lowest interface, i.e. the CAN > network device layer. That should be done in a way which makes porting > CAN low-level drivers between the standard kernel and a real-time Linux > CAN stack trivial. That's a unique chance (compared to the situation of > RTnet e.g.), so we should take it. > > (..) This means we could end up with portable CAN > applications and drivers, RT and non-RT! > As the RTDM and a 'standard'-netdevice are quite similar (in opposite to the former used char-devices for CAN-drivers) it should be quite easy to create some kind of CAN-HW-abstraction layer to fit the bare controller access into a netdevice and respectively a RTDM-device. As both sides currently support various CAN-controllers this is a really good chance to bring not only the socket-API (for the user software) but the low level can driver API (for the driver developer) together. > As Robert said, it "just" requires some resources for implementing > this... ;) I'm looking forward to create this CAN-HW-abstraction layer with Jan and Robert, as i assume the required ressources to be melting down after a initial work that is done together in the approved way. After this is defined, it shall be very easy for driver developers to make their CAN-HW work as netdevice / RTDM-device. So every work is just done once. Finally i wish you a happy new year in advance! May 2006 be the year of excellent (and settled) CAN-concepts inside the Linux kernel for all of us ;-) Best regards, Oliver
