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

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]

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

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 real-time stack is to be derived from the RT-SJA1000 driver
Wolfgang pointed at. It is already based on an abstraction layer (RTDM)
that makes it portable across many of the various RT-Linux variant. So
far this includes support for Xenomai and RTAI, RTLinux/GPL is planning
to adopt RTDM as well. This means we could end up with portable CAN
applications and drivers, RT and non-RT!

As Robert said, it "just" requires some resources for implementing
this... ;)

Jan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

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

[Hartkopp, Oliver (K-GEFE/E)]

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

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

[Robert Schwebel]

Hi Oliver, 

On Fri, Dec 30, 2005 at 07:00:54PM +0100, Hartkopp, Oliver (K-GEFE/E)
wrote:
> > 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