AW: [Socket-can] Re: Which CAN driver to port to for PPC

Hi all,

Robert Schwebel wrote:

quoted

...
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

Hi Oliver, 

On Fri, Dec 30, 2005 at 07:00:54PM +0100, Hartkopp, Oliver (K-GEFE/E)
wrote:

quoted

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.

Writing device drivers will be easy - Sascha has done drivers for
SJA1000 based boards in less than a day and for completely new and
braindamaged chips in less than a week.  

The _real_ work will be on the infrastructure side; to be useful for a
wider audience the existing code has to be forward ported to the latest
2.6 trees and it has to be ported to use modern kernel techniques; even
our 2.6 code suffers a bit from it's history and doesn't use all the
mechanisms the kernel offers today.

We surely could do this, especially Marc and Sascha have quite some
experience with CAN and the network stack, but as always the rule is
that paying customers come first. So as long as there is nobody
sponsoring this project we will work on it only in our sparetime. 

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 ;-)

Let's hope this! :-)

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9