CAN Options and Licensing, Testing, etc

[Joel Sherrill]

On Tue, Apr 12, 2022 at 12:39 PM Oliver Hartkopp <socketcan at hartkopp.net>
wrote:

> Hi Joel,
>
> at least for the SocketCAN network layer part the license is a dual
> license BSD3/GPLv2
>
> // SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
>
> https://elixir.bootlin.com/linux/v5.17.2/source/net/can/af_can.c#L1
>
> The reason was that we (at Volkswagen) intended the idea, the API, (CAN)
> data structures and code could be easily ported to BSD/MacOS/Windows.
>
> In fact we created a working Windows PoC but CAN hardware vendors had no
> interest to unify a open CAN driver API - to maintain their Lock-In :-/
>
> Today only a few CAN network drivers in linux/drivers/net/can follow
> this dual license approach. As they are 'Linux-specific' they are mostly
> GPLv2.
>

Thanks for clarifying that.

The PowerPC qoriq network drivers in libbsd are dual licensed and there
is some framework included to support Linux drivers in libbsd. That's the
extent of my knowledge but it at least means this could be possible to
integrate without knowingly diving into a deep pit.

It has the disadvantage that CAN support would be tied to using libbsd.
That's likely  too heavy for some environments. But might be a good
solution if portability of applications is a goal.


> Best regards,
> Oliver
>
>
> On 12.04.22 19:13, Prashanth S wrote:
> > Hi All,
> >
> > This is to ask for suggestions on implementing the CAN driver for BBB.
> >
> > Can I proceed with defining driver specific structures for the CAN
> > driver or go with adding a generic API layer for ADC and GPIO.
>

Have you determined how you will test CAN on BBB?

I imagine you can use libdebugger to debug CAN.

A big part of the community part of GSoC is making sure you are
in a good position to succeed. That means knowing how you will
test.

--joel

--joel


> >
> > Regards
> > Prashanth S
> >
> >
> > On Tue, 12 Apr 2022 at 19:14, Joel Sherrill <joel at rtems.org
> > <mailto:joel at rtems.org>> wrote:
> >
> >     Hi
> >
> >     I didn't want to post this in the other thread and turn it from a
> >     technical into licensing discussion but that must be the first
> >     filter for a CAN solution for RTEMS if it uses third-party code. If
> >     I have extracted the options correctly, we have:
> >
> >     + LinCAN - GPL
> >     + SocketCAN - GPL
> >     + NuttX CAN - Apache
> >     + CANOpen - Apache
> >
> >     The licensing alone eliminates two of the solutions.
> >
> >     My other concern was how you were going to test the drivers you
> >     wrote. Pavel mentions CAN in qemu. Perhaps the project should drop
> >     the ADC and focus on a CAN solution using the BSP supported by Qemu
> >     along with whatever analysis tools Pavel recommends. I am sure Pavel
> >     has some driver code for the Qemu path (not sure if it is in RTEMS
> >     or not) This would move the project from a single driver to trying
> >     to provide a CAN solution. This is much more valuable to the project
> >     long term.
> >
> >     And since CANOpen is an independent and long running project, I'd
> >     lean to it as the selection.
> >
> >     Just my thoughts
> >
> >     --joel
> >
> >
>