adding can4linux to drivers/char

adding can4linux to drivers/char

[Heinz-Jürgen Oertel]

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

Hello Linux CAN community,

long before SocketCAN, which now is part of the Linux kernel drivers, can4linux was available as the CAN device driver for Linux.

I now like to add it to the kernel source tree as well. What to you think about it. And how should I start and proceed?
I would like to start with the Xilinx XCANPS as can be found on the Zynq processor. Maybe also with one PCI board, the CPC-PCI (EMS Wünsche).

What is the best way? My current development for the PC is based on OpenSuse with kernel 3.7.10. for Xilinx it is kernel 3.10. Can I send a patch against 3.7 and to whom can I send it?

Hope to get some answers helping me with the project. Thanks.
-- 
mit freundlichen Grüßen
       Heinz-Jürgen Oertel

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: adding can4linux to drivers/char

[Oliver Hartkopp]

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

On 21.09.2013 01:03, Heinz-Jürgen Oertel wrote:
> Hello Linux CAN community,
> 
> long before SocketCAN, which now is part of the Linux kernel drivers, can4linux was available as the CAN device driver for Linux.
> 
> I now like to add it to the kernel source tree as well. What to you think about it. And how should I start and proceed?
> I would like to start with the Xilinx XCANPS as can be found on the Zynq processor. Maybe also with one PCI board, the CPC-PCI (EMS Wünsche).
> 
> What is the best way? My current development for the PC is based on OpenSuse with kernel 3.7.10. for Xilinx it is kernel 3.10. Can I send a patch against 3.7 and to whom can I send it?

Hello Heinz,

merging the two different approaches makes sense in that way that the
different users of the can4linux character device API should be able to take
part of the Linux mainline improvements.

The question is how to make it a win-win for both sides without doing double work:

1. SocketCAN & can4linux users should be able to use a common CAN driver pool
2. The netdev and the chardev should be able to run simultaneously
3. The chardev API preferably should support all chardev flavours

Indeed i did some evaluations about the migration from the chardev API of
can4linux to SocketCAN in my thesis on page 156ff

(unfortunately in german)
A.8 Migration existierender CAN Anwendungen

You might get the thesis from here:
http://edoc.bibliothek.uni-halle.de/servlets/DocumentServlet?id=9738

In chapter 8.2 there's a concept describing the co-existence of a character
device emulator and how to connect it to the existing Linux CAN
infrastructure. A screenshot from that picture is attached to this mail.

The advantages of this approach:

- only one hardware driver pool to maintain (e.g. add Xilinx as netdev driver)
- SocketCAN and can4linux apps can run simultaneously on the same CAN hardware
- SocketCAN protocols CAN_BCM and the CAN gateway CAN_GW are still operational
- a compact and easy maintainable chardev API adapter emulation
- can4linux API users get access to all existing CAN netdev drivers (USB, ...)

A real good thing would be if the chardev emulation adapter would support
different chardev flavours like can4linux, PEAK, LinCAN, ...

Of course there would be something to do for the existing infrastructure too.

E.g. the netlink configuration interface for the bitrate settings has to be
made accessible for the chardev emulator. Probably features of the chardev
concepts have to be integrated into the mainline CAN driver infrastruture.
Thinking about hardware filters: These can be easily emulated by the SocketCAN
filter lists, that are per-socket anyway (see picture).

Any thoughts about this idea?

Regards,
Oliver


[-- Attachment #2: chardev_emu.png --]
[-- Type: image/png, Size: 6846 bytes --]

Re: adding can4linux to drivers/char

[Marc Kleine-Budde]

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

On 09/21/2013 01:03 AM, Heinz-Jürgen Oertel wrote:
> long before SocketCAN, which now is part of the Linux kernel drivers,
> can4linux was available as the CAN device driver for Linux.
> 
> I now like to add it to the kernel source tree as well. What to you
> think about it. And how should I start and proceed?

I suggest to port you existing applications to linux-can. I'm sure
you'll find help here and there are several companies out there who
offer commercial support on this.

From my point of view, it quite unlikely that this code will be merged
to mainline, as there is already a working solution.

regards,
Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


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

Re: adding can4linux to drivers/char

[Sebastian Haas]

As Oliver already pointed out there are a bunch of applications outside
which may require a can4linux-like chardev API.

But I also agree that merging an additional CAN framework makes not
much sense. I prefer to port can4linux drivers to SocketCAN for not
yet supported devices. But we may also think about an emulation of
chardev based APIs like can4linux to support legacy applications.

-Sebastian

2013/9/21 Marc Kleine-Budde <mkl@pengutronix.de>:
> On 09/21/2013 01:03 AM, Heinz-Jürgen Oertel wrote:
>> long before SocketCAN, which now is part of the Linux kernel drivers,
>> can4linux was available as the CAN device driver for Linux.
>>
>> I now like to add it to the kernel source tree as well. What to you
>> think about it. And how should I start and proceed?
>
> I suggest to port you existing applications to linux-can. I'm sure
> you'll find help here and there are several companies out there who
> offer commercial support on this.
>
> From my point of view, it quite unlikely that this code will be merged
> to mainline, as there is already a working solution.
>
> regards,
> Marc
>
> --
> Pengutronix e.K.                  | Marc Kleine-Budde           |
> Industrial Linux Solutions        | Phone: +49-231-2826-924     |
> Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
> Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |
>

Re: adding can4linux to drivers/char

[Marc Kleine-Budde]

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

On 09/21/2013 06:37 PM, Sebastian Haas wrote:
> As Oliver already pointed out there are a bunch of applications outside
> which may require a can4linux-like chardev API.
> 
> But I also agree that merging an additional CAN framework makes not
> much sense. I prefer to port can4linux drivers to SocketCAN for not
> yet supported devices. But we may also think about an emulation of
> chardev based APIs like can4linux to support legacy applications.

The emulation could probably be done in userspace. I'll ask our
userspace graphics guys how they emulate legacy /dev/fbX on top of drm.

Marc
-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


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

Re: adding can4linux to drivers/char

[Oliver Hartkopp]

On 21.09.2013 19:09, Marc Kleine-Budde wrote:
> On 09/21/2013 06:37 PM, Sebastian Haas wrote:
>> As Oliver already pointed out there are a bunch of applications outside
>> which may require a can4linux-like chardev API.
>>
>> But I also agree that merging an additional CAN framework makes not
>> much sense. I prefer to port can4linux drivers to SocketCAN for not
>> yet supported devices. But we may also think about an emulation of
>> chardev based APIs like can4linux to support legacy applications.
> 
> The emulation could probably be done in userspace. I'll ask our
> userspace graphics guys how they emulate legacy /dev/fbX on top of drm.
> 

Oh yes!

If there would be a solution to handle all this within a user-space driver
this would be my favorite solution too.

Btw. investing in a SocketCAN port is definitely a long-term solution for CAN
applications and should be the preferred way to go.

Regards,
Oliver

Re: adding can4linux to drivers/char

[Wolfgang Grandegger]

On 09/21/2013 01:03 AM, Heinz-Jürgen Oertel wrote:
> Hello Linux CAN community,
> 
> long before SocketCAN, which now is part of the Linux kernel drivers, can4linux was available as the CAN device driver for Linux.
> 
> I now like to add it to the kernel source tree as well. What to you think about it. And how should I start and proceed?
> I would like to start with the Xilinx XCANPS as can be found on the Zynq processor. Maybe also with one PCI board, the CPC-PCI (EMS Wünsche).
> 
> What is the best way? My current development for the PC is based on OpenSuse with kernel 3.7.10. for Xilinx it is kernel 3.10. Can I send a patch against 3.7 and to whom can I send it?
> 
> Hope to get some answers helping me with the project. Thanks.

I fully share Marc's opinion. There is a working and portable driver
interface for the CAN bus. Why adding another one to the Linux kernel? I
think you need *strong* arguments to get it accepted. There might be
some CAN controllers not yet supported in Linux-CAN but I think it's
better (for the community) to invest in providing and posting Linux-CAN
patches for those devices instead. Porting can4linux applications to
Linux-CAN should be straight-forward and not a big deal.

Wolfgang.

Re: adding can4linux to drivers/char

[Wolfgang Grandegger]

On 09/21/2013 11:17 AM, Oliver Hartkopp wrote:
> On 21.09.2013 01:03, Heinz-Jürgen Oertel wrote:
>> Hello Linux CAN community,
>>
>> long before SocketCAN, which now is part of the Linux kernel drivers, can4linux was available as the CAN device driver for Linux.
>>
>> I now like to add it to the kernel source tree as well. What to you think about it. And how should I start and proceed?
>> I would like to start with the Xilinx XCANPS as can be found on the Zynq processor. Maybe also with one PCI board, the CPC-PCI (EMS Wünsche).
>>
>> What is the best way? My current development for the PC is based on OpenSuse with kernel 3.7.10. for Xilinx it is kernel 3.10. Can I send a patch against 3.7 and to whom can I send it?
> 
> Hello Heinz,
> 
> merging the two different approaches makes sense in that way that the
> different users of the can4linux character device API should be able to take
> part of the Linux mainline improvements.
> 
> The question is how to make it a win-win for both sides without doing double work:
> 
> 1. SocketCAN & can4linux users should be able to use a common CAN driver pool
> 2. The netdev and the chardev should be able to run simultaneously
> 3. The chardev API preferably should support all chardev flavours
> 
> Indeed i did some evaluations about the migration from the chardev API of
> can4linux to SocketCAN in my thesis on page 156ff
> 
> (unfortunately in german)
> A.8 Migration existierender CAN Anwendungen
> 
> You might get the thesis from here:
> http://edoc.bibliothek.uni-halle.de/servlets/DocumentServlet?id=9738
> 
> In chapter 8.2 there's a concept describing the co-existence of a character
> device emulator and how to connect it to the existing Linux CAN
> infrastructure. A screenshot from that picture is attached to this mail.
> 
> The advantages of this approach:
> 
> - only one hardware driver pool to maintain (e.g. add Xilinx as netdev driver)
> - SocketCAN and can4linux apps can run simultaneously on the same CAN hardware
> - SocketCAN protocols CAN_BCM and the CAN gateway CAN_GW are still operational
> - a compact and easy maintainable chardev API adapter emulation
> - can4linux API users get access to all existing CAN netdev drivers (USB, ...)
> 
> A real good thing would be if the chardev emulation adapter would support
> different chardev flavours like can4linux, PEAK, LinCAN, ...

*No*, please not, at least not as part of the Linux kernel. People
should port their applications to Linux-CAN and then they will
automatically profit from further improvements.

Wolfgang.

Re: adding can4linux to drivers/char

[Marc Kleine-Budde]

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

On 09/22/2013 08:39 AM, Sebastian Haas wrote:
>> If there would be a solution to handle all this within a user-space driver
>> this would be my favorite solution too.
> Just found CUSE made by Tejun. It is in mainline since 2.6.31. I'm going
> to implement a demo for this.

+1

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


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

Re: adding can4linux to drivers/char

[Oliver Hartkopp]

On 22.09.2013 08:39, Sebastian Haas wrote:
> Am 21.09.2013 20:17 schrieb "Oliver Hartkopp" <socketcan@hartkopp.net
> <mailto:socketcan@hartkopp.net>>:
>>
>> On 21.09.2013 19:09, Marc Kleine-Budde wrote:
>> > On 09/21/2013 06:37 PM, Sebastian Haas wrote:
>> >> As Oliver already pointed out there are a bunch of applications outside
>> >> which may require a can4linux-like chardev API.
>> >>
>> >> But I also agree that merging an additional CAN framework makes not
>> >> much sense. I prefer to port can4linux drivers to SocketCAN for not
>> >> yet supported devices. But we may also think about an emulation of
>> >> chardev based APIs like can4linux to support legacy applications.
>> >
>> > The emulation could probably be done in userspace. I'll ask our
>> > userspace graphics guys how they emulate legacy /dev/fbX on top of drm.
>> >
>>
>> Oh yes!
>>
>> If there would be a solution to handle all this within a user-space driver
>> this would be my favorite solution too.
> Just found CUSE made by Tejun. It is in mainline since 2.6.31. I'm going to
> implement a demo for this.

CUSE really looks promising for legacy CAN APIs!

With that idea every vendor(!) can implement an own CUSE driver to support
_their_ costumers to run legacy apps the customers are not able/willing to
port to native SocketCAN. And then vendor becomes the correct contact person
for his own CAN API and his own CUSE adapter too. A good separation!

I agree with Wolfgang that porting applications to Linux-CAN is the strongly
recommended way. Especially because of the simple SocketCAN API this should be
easy to do in the vast majority of cases.

And adding the few missing drivers (like the Xilinx) as a netdevice driver to
drivers/net/can should be no big deal at all. I assume Xilinx would also be
happy to have their hardware supported by the Linux mainline standard.

Best regards,
Oliver

ps. A prominent project which is using the CUSE concept is the 'OSS proxy'
which creates e.g. legacy /dev/dsp devices used by the Open Sound System.
OSS was the former sound system API standard in Linux 2.4.

https://fedoraproject.org/wiki/Features/OSSProxy
http://sourceforge.net/projects/osspd/

Re: adding can4linux to drivers/char

[Marc Kleine-Budde]

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

On 09/21/2013 07:09 PM, Marc Kleine-Budde wrote:
> On 09/21/2013 06:37 PM, Sebastian Haas wrote:
>> As Oliver already pointed out there are a bunch of applications outside
>> which may require a can4linux-like chardev API.
>>
>> But I also agree that merging an additional CAN framework makes not
>> much sense. I prefer to port can4linux drivers to SocketCAN for not
>> yet supported devices. But we may also think about an emulation of
>> chardev based APIs like can4linux to support legacy applications.
> 
> The emulation could probably be done in userspace. I'll ask our
> userspace graphics guys how they emulate legacy /dev/fbX on top of drm.

They use CUSE, too.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


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

Re: adding can4linux to drivers/char

[Heinz-Jürgen Oertel]

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


Hello

Am Samstag, 21. September 2013, 21:55:45 schrieb Wolfgang Grandegger:
> I think you need *strong* arguments to get it accepted. 

I have some good arguments for this kind of driver
- it is much more simple in design than others,
  simplicity is one of the Linux design goals
- It has a simple user API
- It does not need any other infrastructure than the kernel API
- It is mature

I agree, it would be nice to share the low level CAN controller related 
experiences of the developers. That is may be something we can share if we 
could agree of a set of CAN controller header files with shared register 
#defines. And a set of very basic functions like initialize and activate CAN, 
set acceptance filters, transmit and receive, read out error register or 
whatever.
But to stay simple, I don't like the idea to have another additional layer 
around SocketCAN as layer below the can4linux API.

Linux offers real diversity on the desktop, why not with drivers? Linux also 
has different sound devices and architectures.  Why not offering two different 
CAN driver concepts to the application programmer,
let she decide what to use.

-- 
mit freundlichen Grüßen
       Heinz-Jürgen Oertel

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: adding can4linux to drivers/char

[Marc Kleine-Budde]

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

On 09/29/2013 06:28 PM, Heinz-Jürgen Oertel wrote:
> Am Samstag, 21. September 2013, 21:55:45 schrieb Wolfgang Grandegger:
>> I think you need *strong* arguments to get it accepted. 
> 
> I have some good arguments for this kind of driver
> - it is much more simple in design than others,
>   simplicity is one of the Linux design goals

What is in your opinion too complicated about linux CAN? Is it a lack of
Documentation or examples?

> - It has a simple user API

For a simple program you need socket(), bind(), read(), write().

> - It does not need any other infrastructure than the kernel API

This is another way of telling, we've reinvented the rest on our own.

> - It is mature

The ultimate question is: What problem does it solve?

> I agree, it would be nice to share the low level CAN controller related 
> experiences of the developers. That is may be something we can share if we 
> could agree of a set of CAN controller header files with shared register 
> #defines. And a set of very basic functions like initialize and activate CAN, 
> set acceptance filters, transmit and receive, read out error register or 
> whatever.

Like the driver and the socket infrastructure?

> But to stay simple, I don't like the idea to have another additional layer 
> around SocketCAN as layer below the can4linux API.

Does this mean you want to duplicate the drivers?

> Linux offers real diversity on the desktop, why not with drivers? Linux also 
> has different sound devices and architectures.  Why not offering two different 
> CAN driver concepts to the application programmer,
> let she decide what to use.

Sorry, but I can only NAK this idea.

Marc
-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


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

Re: adding can4linux to drivers/char

[Sebastian Haas]

I think Heinz-Jürgens' arguments are not that wrong. There are a bunch
of example in the kernel of concurring solution for the same issues
every single one with different advantages and disadvantages (just
compare how many solution for virtualization are available kvm, xen,
paravirt, ...).

There must be space in kernel for the classical chardev CAN-approach.
Sharing common code to access the different controllers must be
possible.

I think there are a bunch of use cases out there which are easier and
more efficiently solved with a simple chardev API. A simple chardev
CAN driver like can4linux provide doesn't depend on the whole
networking subsystem which may be imported of real embedded systems
with strong memory constraints (less memory footprint, smaller
kernel).

The Socket approach has some real advantages (multi-user for single
CAN controller, iptables filtering, netutil integration, buffering,
..), but many of them may be considered as disadvantages as well (no
control of the message flow in terms of timing and ordering, no
exclusive use of the interface, networking dependency). Implementing
an automatic bitrate detection or application driver busoff recovery
is a pain in the ass with SocketCAN.

-Sebastian

2013/9/29 Heinz-Jürgen Oertel <hj.oertel@t-online.de>:
>
> Hello
>
> Am Samstag, 21. September 2013, 21:55:45 schrieb Wolfgang Grandegger:
>> I think you need *strong* arguments to get it accepted.
>
> I have some good arguments for this kind of driver
> - it is much more simple in design than others,
>   simplicity is one of the Linux design goals
> - It has a simple user API
> - It does not need any other infrastructure than the kernel API
> - It is mature
>
> I agree, it would be nice to share the low level CAN controller related
> experiences of the developers. That is may be something we can share if we
> could agree of a set of CAN controller header files with shared register
> #defines. And a set of very basic functions like initialize and activate CAN,
> set acceptance filters, transmit and receive, read out error register or
> whatever.
> But to stay simple, I don't like the idea to have another additional layer
> around SocketCAN as layer below the can4linux API.
>
> Linux offers real diversity on the desktop, why not with drivers? Linux also
> has different sound devices and architectures.  Why not offering two different
> CAN driver concepts to the application programmer,
> let she decide what to use.
>
> --
> mit freundlichen Grüßen
>        Heinz-Jürgen Oertel

Re: adding can4linux to drivers/char

[Marc Kleine-Budde]

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

On 09/29/2013 07:45 PM, Sebastian Haas wrote:
> I think Heinz-Jürgens' arguments are not that wrong. There are a bunch
> of example in the kernel of concurring solution for the same issues
> every single one with different advantages and disadvantages (just
> compare how many solution for virtualization are available kvm, xen,
> paravirt, ...).

You're right.

> There must be space in kernel for the classical chardev CAN-approach.
> Sharing common code to access the different controllers must be
> possible.

That's already implemented in the Kernel, it's called a driver.

> I think there are a bunch of use cases out there which are easier and
> more efficiently solved with a simple chardev API. A simple chardev
> CAN driver like can4linux provide doesn't depend on the whole
> networking subsystem which may be imported of real embedded systems
> with strong memory constraints (less memory footprint, smaller
> kernel).

The smallest system we're running Linux is a Cortex M3, it's on chip RAM
is to small for Kernel + Userspace, so you need an external RAM chip
anyways.

> The Socket approach has some real advantages (multi-user for single
> CAN controller, iptables filtering, netutil integration, buffering,
> ..), but many of them may be considered as disadvantages as well (no
> control of the message flow in terms of timing and ordering, no

You you have ordering problem? That's a bug? Which driver/hardware?

> exclusive use of the interface, networking dependency). Implementing
> an automatic bitrate detection or application driver busoff recovery
> is a pain in the ass with SocketCAN.

If there is a need for bitrate detection, feel free request it here. I
think there are some controllers that support this in hardware, while
others don't. Is there a known working algorithm for bitrate detection?
How can we make busoff recovery better? What's the most annoying point?

Marc
-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


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

Re: adding can4linux to drivers/char

[Heinz-Jürgen Oertel]

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

Am Sonntag, 29. September 2013, 19:23:42 schrieb Max S.:
> Additionally when using micros with on-board CAN controllers the RX pin
> can be temporarily reprogrammed to an input. With a pin change interrupt
> and a timer it is then possible to measure the TQ used by other nodes.

That is the method which Infineon suggested, isn't it?
-- 
mit freundlichen Grüßen
       Heinz-Jürgen Oertel

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: adding can4linux to drivers/char

[Heinz-Jürgen Oertel]

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

Sebastion,
thanks for at least being open for my arguments.

Am Sonntag, 29. September 2013, 19:45:09 schrieb Sebastian Haas:
> The Socket approach has some real advantages (multi-user for single
> CAN controller,

I like only comment this one.
Multiple applications can of course share one device in can4linux.

And Marc, because some of the drivers exist much longer than SocketCAN,
one should be respectful and don't name only one driver 'linux CAN'. 

-- 
mit freundlichen Grüßen
       Heinz-Jürgen Oertel

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: adding can4linux to drivers/char

[Max S.]

This isn't on topic to this thread...
Just thought I'd note:

On Sun, 2013-09-29 at 20:44 +0200, Marc Kleine-Budde wrote:
> If there is a need for bitrate detection, feel free request it here. I
> think there are some controllers that support this in hardware, while
> others don't. Is there a known working algorithm for bitrate detection?

Most controllers have listen only mode, in which the error counters are
frozen. It is then possible to systematically try all common bit-rate
configurations, and listen for good frames. works best when you start
with high speeds and work your way down. Listen only mode baud sniffing
will require at least two other nodes (one to send, one to ack..)

Some controllers also have a mode similar to listen only, but that also
internally connect the TX signal to the RX signal. this way you only
need 1 other node to send non acked frames. the autobauding node will
then ack those frames for itself only. Atmel calls this mode LOOPBACK...
even though its not a typical "LOOPBACK".

Additionally when using micros with on-board CAN controllers the RX pin
can be temporarily reprogrammed to an input. With a pin change interrupt
and a timer it is then possible to measure the TQ used by other nodes.

Re: adding can4linux to drivers/char

[Wolfgang Grandegger]

On 09/29/2013 06:28 PM, Heinz-Jürgen Oertel wrote:
> 
> Hello
> 
> Am Samstag, 21. September 2013, 21:55:45 schrieb Wolfgang Grandegger:
>> I think you need *strong* arguments to get it accepted. 
> 
> I have some good arguments for this kind of driver
> - it is much more simple in design than others,
>   simplicity is one of the Linux design goals
> - It has a simple user API
> - It does not need any other infrastructure than the kernel API
> - It is mature

Well, the question is in what respect it's (much) better than the
existing Linux-CAN. I can imagine some performance benefits on very low
end systems, if at all.

> I agree, it would be nice to share the low level CAN controller related 
> experiences of the developers. That is may be something we can share if we 
> could agree of a set of CAN controller header files with shared register 
> #defines. And a set of very basic functions like initialize and activate CAN, 
> set acceptance filters, transmit and receive, read out error register or 
> whatever.

Sounds ugly!

> But to stay simple, I don't like the idea to have another additional layer 
> around SocketCAN as layer below the can4linux API.
> 
> Linux offers real diversity on the desktop, why not with drivers? Linux also 
> has different sound devices and architectures.  Why not offering two different 
> CAN driver concepts to the application programmer,
> let she decide what to use.


It's also about maintenance. It's real work to keep a driver in the
kernel up-to-date, to review and accept new drivers, etc., not only for
the initial submitter.

There are missing bits and pieces in Linux-CAN, e.g. hardware filter
support, improved bus-off handling or even bitrate detection. That's
also not a strong argument for can4linux. Just contribute them to Linux-CAN.

Wolfgang.

autobaud detection (was: Re: adding can4linux to drivers/char)

[Marc Kleine-Budde]

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

On 09/29/2013 09:23 PM, Max S. wrote:
> This isn't on topic to this thread...

I've changed the topic :P

> Just thought I'd note:

Thanks.

> On Sun, 2013-09-29 at 20:44 +0200, Marc Kleine-Budde wrote:
>> If there is a need for bitrate detection, feel free request it here. I
>> think there are some controllers that support this in hardware, while
>> others don't. Is there a known working algorithm for bitrate detection?
> 
> Most controllers have listen only mode, in which the error counters are
> frozen. It is then possible to systematically try all common bit-rate
> configurations, and listen for good frames. works best when you start
> with high speeds and work your way down. Listen only mode baud sniffing
> will require at least two other nodes (one to send, one to ack..)

This sounds pretty straight forward. This can be implemented as a
userspace library. Pseudo code:

The function get the can interface name as a string, an optional  0
terminated array of bitrates (must be sorted or we sort internally) if
NULL a default array is used, a pointer to an int that will be written
if the bitrate is found and a timeout value in ms. The code waits for X
ms for a good frame to arrive.

int can_autobitrate(const char *interface, const int bitrate_array[],
                    int *autobitrate, int timeout_ms)
{
	struct pollfd fds[1];
	int s, ret = 0;

	err = can_set_listenonly(interface);
	if (err)
		return err;

	s = socket(interface);
	fds[1].fd = s;
	fds[1].events = POLLIN;

	if (!bitrate_array)
		bitrate_array = default_bitrate_array;

	for (i = 0; bitrate_array[i]; i++) {
		can_ifdown(interface);
		can_set_bitrate(interface, bitrate_array[i]);
		can_ifup(interface);

		/* wait for good frame comming in */
		ret = poll(fds, 1, timeout_ms);
		if (ret == 1 && fds[1].revents & POLLIN) {
			*bitrate = bitrate_array[i];
			goto out:
		}
		proper_error_handling();
	}
	ret = -1;

out:
	close(s);
	set_normal_mode(interface);
}


> Some controllers also have a mode similar to listen only, but that also
> internally connect the TX signal to the RX signal. this way you only
> need 1 other node to send non acked frames. the autobauding node will
> then ack those frames for itself only. Atmel calls this mode LOOPBACK...
> even though its not a typical "LOOPBACK".

This new mode can be easily added to the other control mode, we just
have to define a proper name.

> Additionally when using micros with on-board CAN controllers the RX pin
> can be temporarily reprogrammed to an input. With a pin change interrupt
> and a timer it is then possible to measure the TQ used by other nodes.

Nice, with modern Device Tree based Kernels that is also possible. You
can describe alternative pinmux settings for a device in a hardware
independent way.

Marc
-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


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

Re: adding can4linux to drivers/char

[Sebastian Haas]

Am 29.09.2013 20:44 schrieb "Marc Kleine-Budde" <mkl@pengutronix.de>:
>
> On 09/29/2013 07:45 PM, Sebastian Haas wrote:
> > I think Heinz-Jürgens' arguments are not that wrong. There are a bunch
> > of example in the kernel of concurring solution for the same issues
> > every single one with different advantages and disadvantages (just
> > compare how many solution for virtualization are available kvm, xen,
> > paravirt, ...).
>
> You're right.
>
> > There must be space in kernel for the classical chardev CAN-approach.
> > Sharing common code to access the different controllers must be
> > possible.
>
> That's already implemented in the Kernel, it's called a driver.
You think I'm an idiot, don't you?

> > I think there are a bunch of use cases out there which are easier and
> > more efficiently solved with a simple chardev API. A simple chardev
> > CAN driver like can4linux provide doesn't depend on the whole
> > networking subsystem which may be imported of real embedded systems
> > with strong memory constraints (less memory footprint, smaller
> > kernel).
>
> The smallest system we're running Linux is a Cortex M3, it's on chip RAM
> is to small for Kernel + Userspace, so you need an external RAM chip
> anyways.
RAM is not the only limiting factor there is memory out there called flash or
ROM and then we are talking about code size and required tools to use a
specific features. And you know what I wrote whole CAN drivers with as much
LOC as libsocketcan.

In a system with just 2MB flash and no need for networking stuff except CAN
every 10KB counts. To get a full features Socket CAN installation on such a
system you need the networking subsystem, iputils and libsocketcan whereas
a chardev solution is much more leaner, you just need the driver and your app
- that's it.

> > The Socket approach has some real advantages (multi-user for single
> > CAN controller, iptables filtering, netutil integration, buffering,
> > ..), but many of them may be considered as disadvantages as well (no
> > control of the message flow in terms of timing and ordering, no
>
> You you have ordering problem? That's a bug? Which driver/hardware?
I didn't say I have an ordering bug, but due to the queuing the messages
on sending you loose control _when_ a message is actually sent and if it was
sent. On Socket-CAN I can only guess if the message was sent. If you want
to couple this with an automatic bitrate detection which relies on sending
messages (e.g. SafetyBus p) in a different pattern this is simple not possible.

> > exclusive use of the interface, networking dependency). Implementing
> > an automatic bitrate detection or application driver busoff recovery
> > is a pain in the ass with SocketCAN.
>
> If there is a need for bitrate detection, feel free request it here. I
> think there are some controllers that support this in hardware, while
> others don't. Is there a known working algorithm for bitrate detection?
There are different approaches described. The one Max described (passive
detection) is feasible with SocketCAN+libsocketcan and only if the bus
is already
communication. Active detection algorithm (I already mentioned SafetyBus p) are
really hard to realize with Socket-CAN cause of the queuing stuff.

> How can we make busoff recovery better? What's the most annoying point?
The automatic recovery is fine, but the manual recovery needs NETIF stuff or
libsocketcan.

But again I'm not saying Socket-CAN is bullshit, it is good for desktop use and
for embedded system with enough resources. When it comes to deterministic
requirements (and don't come with that SocketCAN Xenomai stuff, you don't
solve stuff if you put more code on top of it, keep it simple) and a
lean, simple
and efficient use it wouldn't be my first choice. So why shouldn't we
try to share
drivers code without netdev dependencies and allow the user to have a chardev
interface as well with the well known behavior behind?

-Sebastian

Re: adding can4linux to drivers/char

[Sebastian Haas]

2013/9/29 Wolfgang Grandegger <wg@grandegger.com>:
> On 09/29/2013 06:28 PM, Heinz-Jürgen Oertel wrote:
>>
>> Hello
>>
>> Am Samstag, 21. September 2013, 21:55:45 schrieb Wolfgang Grandegger:
>>> I think you need *strong* arguments to get it accepted.
>>
>> I have some good arguments for this kind of driver
>> - it is much more simple in design than others,
>>   simplicity is one of the Linux design goals
>> - It has a simple user API
>> - It does not need any other infrastructure than the kernel API
>> - It is mature
>
> Well, the question is in what respect it's (much) better than the
> existing Linux-CAN. I can imagine some performance benefits on very low
> end systems, if at all.
Again think about memory (RAM/ROM) as well. We are talking here about small
ARM7TDMI stuff and other creepy and limited systems.

>> I agree, it would be nice to share the low level CAN controller related
>> experiences of the developers. That is may be something we can share if we
>> could agree of a set of CAN controller header files with shared register
>> #defines. And a set of very basic functions like initialize and activate CAN,
>> set acceptance filters, transmit and receive, read out error register or
>> whatever.
>
> Sounds ugly!
Sharing definitions and common functions sounds ugly to you? What does
the candev
and sja1000dev in Socket CAN does?

>> But to stay simple, I don't like the idea to have another additional layer
>> around SocketCAN as layer below the can4linux API.
>>
>> Linux offers real diversity on the desktop, why not with drivers? Linux also
>> has different sound devices and architectures.  Why not offering two different
>> CAN driver concepts to the application programmer,
>> let she decide what to use.
>
>
> It's also about maintenance. It's real work to keep a driver in the
> kernel up-to-date, to review and accept new drivers, etc., not only for
> the initial submitter.
Right, and I think a chardev drivers has far less dependencies to maintain then
the Socket CAN driver. No netdev changes to maintain, iputils stuff or changes
in the candev ;-)

A reason more trying to share code with a chardev solution!

> There are missing bits and pieces in Linux-CAN, e.g. hardware filter
> support, improved bus-off handling or even bitrate detection. That's
> also not a strong argument for can4linux. Just contribute them to Linux-CAN.
Well, some things can't be done cause of the underlying networking subsystem
(namely the queuing) which is perfectly fine for real networking stuff
(>= IP) but
not that well for CAN IMHO.

-Sebastian

Re: adding can4linux to drivers/char

[Wolfgang Grandegger]

On Mon, 30 Sep 2013 09:40:37 +0200, Sebastian Haas
<dev@sebastianhaas.info> wrote:
> 2013/9/29 Wolfgang Grandegger <wg@grandegger.com>:
>> On 09/29/2013 06:28 PM, Heinz-Jürgen Oertel wrote:
>>>
>>> Hello
>>>
>>> Am Samstag, 21. September 2013, 21:55:45 schrieb Wolfgang Grandegger:
>>>> I think you need *strong* arguments to get it accepted.
>>>
>>> I have some good arguments for this kind of driver
>>> - it is much more simple in design than others,
>>>   simplicity is one of the Linux design goals
>>> - It has a simple user API
>>> - It does not need any other infrastructure than the kernel API
>>> - It is mature
>>
>> Well, the question is in what respect it's (much) better than the
>> existing Linux-CAN. I can imagine some performance benefits on very low
>> end systems, if at all.
> Again think about memory (RAM/ROM) as well. We are talking here about
small
> ARM7TDMI stuff and other creepy and limited systems.

Do you have figures? I remember that the a chardev based solution is not
really
*much* better.

>>> I agree, it would be nice to share the low level CAN controller
related
>>> experiences of the developers. That is may be something we can share
if
>>> we
>>> could agree of a set of CAN controller header files with shared
register
>>> #defines. And a set of very basic functions like initialize and
>>> activate CAN,
>>> set acceptance filters, transmit and receive, read out error register
or
>>> whatever.
>>
>> Sounds ugly!
> Sharing definitions and common functions sounds ugly to you? What does
> the candev
> and sja1000dev in Socket CAN does?

OK, pure share is fine but I had ugly #ifdef's in mind.
 
>>> But to stay simple, I don't like the idea to have another additional
>>> layer
>>> around SocketCAN as layer below the can4linux API.
>>>
>>> Linux offers real diversity on the desktop, why not with drivers?
Linux
>>> also
>>> has different sound devices and architectures.  Why not offering two
>>> different
>>> CAN driver concepts to the application programmer,
>>> let she decide what to use.
>>
>>
>> It's also about maintenance. It's real work to keep a driver in the
>> kernel up-to-date, to review and accept new drivers, etc., not only for
>> the initial submitter.
> Right, and I think a chardev drivers has far less dependencies to
maintain
> then
> the Socket CAN driver. No netdev changes to maintain, iputils stuff or
> changes
> in the candev ;-)
> 
> A reason more trying to share code with a chardev solution!
> 
>> There are missing bits and pieces in Linux-CAN, e.g. hardware filter
>> support, improved bus-off handling or even bitrate detection. That's
>> also not a strong argument for can4linux. Just contribute them to
>> Linux-CAN.
> Well, some things can't be done cause of the underlying networking
> subsystem
> (namely the queuing) which is perfectly fine for real networking stuff
> (>= IP) but
> not that well for CAN IMHO.

I do not say that can4linux is bad but image we have another CAN interface
in the kernel supporting a *different* set of devices... and we will end
up with such a solution sooner than later, for sure. This means that
people
will finally not have the real choice but are forced to use the interface
supporting their device. It breaks portability! I believe that's a *bad*
solution for the community.

Wolfgang.

Re: adding can4linux to drivers/char

[Oliver Hartkopp]

"Heinz-Jürgen Oertel" <hj.oertel@t-online.de> schrieb:
>Sebastion,
>thanks for at least being open for my arguments.

Hello Heinz, 

I was open to your arguments too.

But I'm definitely against including a separate set of CAN drivers into the Kernel. Adding a separate API is ok - but creating separate drivers for the exactly same hardware will not work!

>Am Sonntag, 29. September 2013, 19:45:09 schrieb Sebastian Haas:
>> The Socket approach has some real advantages (multi-user for single
>> CAN controller,
>
>I like only comment this one.
>Multiple applications can of course share one device in can4linux.
>

Yes but people have to learn about all that. And with the 'even easier' known and clean socket API there's a proper separation between the user stuff and the admin interfaces like bitrate setting. There's a reason why developers thank the developers here, when the started with SocketCAN.

>And Marc, because some of the drivers exist much longer than SocketCAN,
>one should be respectful and don't name only one driver 'linux CAN'. 

The reason why SocketCAN was invented was because there was a complete mix of different CAN drivers with thousands of different crappy programming interfaces (mailbox ids in can frame structures) and many vendor lock-ins.

SocketCAN has been discussed at least for two years until it made it's way into mainline. There was no contribution from all the CAN hardware manifacturers except PEAK, which supported SocketCAN in their out-of-tree driver (and now in mainline linux).

Even the 'performance' argument is no argument to go for a different CAN  infrastructure in the kernel. See my thesis or the measurements from the University of Prague comparing the OCAN driver with SocketCAN.

If you feel things are missing, please discuss and contribute them here. It's never too late. But starting a new chardev discussion with all the different chardev flavours from all the different vendors will not fix any problem for Linux users. They will get lost, like it was before SocketCAN. 
Add your currently unsupported hardware as netdev drivers. People will appreciate that. And add a CUSE adaption for your legacy costumers. And if there's anything that's missing or has to be fixed in SocketCAN help us to fix it.

Regards,
Oliver

ps. I'm currently on vacation and this mail was sent from my wifes mobile.  So I'll not be able to answer like you know it from me.


-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Re: adding can4linux to drivers/char

[Kurt Van Dijck]

Hi,

Please find my remarks on this topic below.

On Mon, Sep 30, 2013 at 09:30:09AM +0200, Sebastian Haas wrote:
> Am 29.09.2013 20:44 schrieb "Marc Kleine-Budde" <mkl@pengutronix.de>:
> >
> > On 09/29/2013 07:45 PM, Sebastian Haas wrote:
> > > I think Heinz-Jürgens' arguments are not that wrong. There are a bunch
> > > of example in the kernel of concurring solution for the same issues
> > > every single one with different advantages and disadvantages (just
> > > compare how many solution for virtualization are available kvm, xen,
> > > paravirt, ...).
> >
> > You're right.

You cannot have 1 device with 2 drivers (1 can4linux + 1 linux-can),
because users would need to choose the set of drivers to use.
That choice is made for an application, but must be implemented on a
system level: some udev magic or module blacklisting, or in your
case, compile only 1 set in the kernel.
No arguments exist to provide non-expert users with those choices.

I agree that adding 1 api as emulation layer really suits some usecases.

Linux-CAN is IMHO superior because linux-can preserves
the network semantics in the way that the linux kernel has foreseen.
can4linux may provide network semantics (I'm not specialist there),
but providing network semantics through a chardev is simply wrong.

> > > I think there are a bunch of use cases out there which are easier and
> > > more efficiently solved with a simple chardev API. A simple chardev
> > > CAN driver like can4linux provide doesn't depend on the whole
> > > networking subsystem which may be imported of real embedded systems
> > > with strong memory constraints (less memory footprint, smaller
> > > kernel).

If you put all application logic in 1 binary, you don't need
the multi-user capabilities nor the network semantics.
But that's not the typical scenario, so it shouldn't be abused
to promote single-user or chardev API's.
Bare metal programming, if done well, will always render a more efficient
system, but requires more effort :-)

> >
> > The smallest system we're running Linux is a Cortex M3, it's on chip RAM
> > is to small for Kernel + Userspace, so you need an external RAM chip
> > anyways.
> RAM is not the only limiting factor there is memory out there called flash or
> ROM and then we are talking about code size and required tools to use a
> specific features. And you know what I wrote whole CAN drivers with as much
> LOC as libsocketcan.
> 
> In a system with just 2MB flash and no need for networking stuff except CAN
> every 10KB counts. To get a full features Socket CAN installation on such a
> system you need the networking subsystem, iputils and libsocketcan whereas
> a chardev solution is much more leaner, you just need the driver and your app
> - that's it.
> 
> > > The Socket approach has some real advantages (multi-user for single
> > > CAN controller, iptables filtering, netutil integration, buffering,
> > > ..), but many of them may be considered as disadvantages as well (no
> > > control of the message flow in terms of timing and ordering, no

You compare a stripped chardev solution with a 'full featured' socket CAN,
with iptables & stuff?
You should compare against a 'stripped' socket CAN solution: no iproute,
just libsocketcan. You app will 'up' the netdev.
No ip sockets, no unix sockets, ....
> >
> > You you have ordering problem? That's a bug? Which driver/hardware?
> I didn't say I have an ordering bug, but due to the queuing the messages
> on sending you loose control _when_ a message is actually sent and if it was

The issues you mention only expose themselves in 'real' multi-user systems,
but you have only 1 user. You can predict exactly what is in the queues.
With a chardev API, you would administer queues yourself in application.
You could do this on top of socketCAN too.

> sent. On Socket-CAN I can only guess if the message was sent. If you want
> to couple this with an automatic bitrate detection which relies on sending
> messages (e.g. SafetyBus p) in a different pattern this is simple not possible.

You can retrieve you own sent messages in the same flow.
see commit 1e55659ce6ddb5247cee0b1f720d77a799902b85

> 
> > > exclusive use of the interface, networking dependency).
You had only 1 application running, right?
You know that you have exclusive use then!

[...]
> 
> -Sebastian

Kind regards,

-- 
Kurt Van Dijck

AW: adding can4linux to drivers/char

[May, Stefan]

> And add a CUSE adaption for your legacy costumers.

CUSE adaption is not possible in the case of can4linux API. I tried that once and failed. The reason is in read() and write() call where can4linux chooses to use the number of frames instead of bytes for the count parameter.

mfg, Stefan May.



-----Ursprüngliche Nachricht-----
Von: linux-can-owner@vger.kernel.org im Auftrag von Oliver Hartkopp
Gesendet: Mo 30.09.2013 11:35
An: Heinz-Jürgen Oertel; linux-can@vger.kernel.org
Betreff: Re: adding can4linux to drivers/char
 




"Heinz-Jürgen Oertel" <hj.oertel@t-online.de> schrieb:
>Sebastion,
>thanks for at least being open for my arguments.

Hello Heinz, 

I was open to your arguments too.

But I'm definitely against including a separate set of CAN drivers into the Kernel. Adding a separate API is ok - but creating separate drivers for the exactly same hardware will not work!

>Am Sonntag, 29. September 2013, 19:45:09 schrieb Sebastian Haas:
>> The Socket approach has some real advantages (multi-user for single
>> CAN controller,
>
>I like only comment this one.
>Multiple applications can of course share one device in can4linux.
>

Yes but people have to learn about all that. And with the 'even easier' known and clean socket API there's a proper separation between the user stuff and the admin interfaces like bitrate setting. There's a reason why developers thank the developers here, when the started with SocketCAN.

>And Marc, because some of the drivers exist much longer than SocketCAN,
>one should be respectful and don't name only one driver 'linux CAN'. 

The reason why SocketCAN was invented was because there was a complete mix of different CAN drivers with thousands of different crappy programming interfaces (mailbox ids in can frame structures) and many vendor lock-ins.

SocketCAN has been discussed at least for two years until it made it's way into mainline. There was no contribution from all the CAN hardware manifacturers except PEAK, which supported SocketCAN in their out-of-tree driver (and now in mainline linux).

Even the 'performance' argument is no argument to go for a different CAN  infrastructure in the kernel. See my thesis or the measurements from the University of Prague comparing the OCAN driver with SocketCAN.

If you feel things are missing, please discuss and contribute them here. It's never too late. But starting a new chardev discussion with all the different chardev flavours from all the different vendors will not fix any problem for Linux users. They will get lost, like it was before SocketCAN. 
Add your currently unsupported hardware as netdev drivers. People will appreciate that. And add a CUSE adaption for your legacy costumers. And if there's anything that's missing or has to be fixed in SocketCAN help us to fix it.

Regards,
Oliver

ps. I'm currently on vacation and this mail was sent from my wifes mobile.  So I'll not be able to answer like you know it from me.


-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
--
To unsubscribe from this list: send the line "unsubscribe linux-can" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: adding can4linux to drivers/char

[Oliver Hartkopp]

"May, Stefan" <stefan.may@desy.de> schrieb:
>> And add a CUSE adaption for your legacy costumers.
>
>CUSE adaption is not possible in the case of can4linux API. I tried
>that once and failed. The reason is in read() and write() call where
>can4linux chooses to use the number of frames instead of bytes for the
>count parameter.
>

This is not the standard way :-(

Btw. CUSE is open source.
Why not adding a feature to CUSE that allows to pass the number of structs instead of the number of bytes?

Regards,
Oliver

>mfg, Stefan May.
>
>
>
>-----Ursprüngliche Nachricht-----
>Von: linux-can-owner@vger.kernel.org im Auftrag von Oliver Hartkopp
>Gesendet: Mo 30.09.2013 11:35
>An: Heinz-Jürgen Oertel; linux-can@vger.kernel.org
>Betreff: Re: adding can4linux to drivers/char
> 
>
>
>
>
>"Heinz-Jürgen Oertel" <hj.oertel@t-online.de> schrieb:
>>Sebastion,
>>thanks for at least being open for my arguments.
>
>Hello Heinz, 
>
>I was open to your arguments too.
>
>But I'm definitely against including a separate set of CAN drivers into
>the Kernel. Adding a separate API is ok - but creating separate drivers
>for the exactly same hardware will not work!
>
>>Am Sonntag, 29. September 2013, 19:45:09 schrieb Sebastian Haas:
>>> The Socket approach has some real advantages (multi-user for single
>>> CAN controller,
>>
>>I like only comment this one.
>>Multiple applications can of course share one device in can4linux.
>>
>
>Yes but people have to learn about all that. And with the 'even easier'
>known and clean socket API there's a proper separation between the user
>stuff and the admin interfaces like bitrate setting. There's a reason
>why developers thank the developers here, when the started with
>SocketCAN.
>
>>And Marc, because some of the drivers exist much longer than
>SocketCAN,
>>one should be respectful and don't name only one driver 'linux CAN'. 
>
>The reason why SocketCAN was invented was because there was a complete
>mix of different CAN drivers with thousands of different crappy
>programming interfaces (mailbox ids in can frame structures) and many
>vendor lock-ins.
>
>SocketCAN has been discussed at least for two years until it made it's
>way into mainline. There was no contribution from all the CAN hardware
>manifacturers except PEAK, which supported SocketCAN in their
>out-of-tree driver (and now in mainline linux).
>
>Even the 'performance' argument is no argument to go for a different
>CAN  infrastructure in the kernel. See my thesis or the measurements
>from the University of Prague comparing the OCAN driver with SocketCAN.
>
>If you feel things are missing, please discuss and contribute them
>here. It's never too late. But starting a new chardev discussion with
>all the different chardev flavours from all the different vendors will
>not fix any problem for Linux users. They will get lost, like it was
>before SocketCAN. 
>Add your currently unsupported hardware as netdev drivers. People will
>appreciate that. And add a CUSE adaption for your legacy costumers. And
>if there's anything that's missing or has to be fixed in SocketCAN help
>us to fix it.
>
>Regards,
>Oliver
>
>ps. I'm currently on vacation and this mail was sent from my wifes
>mobile.  So I'll not be able to answer like you know it from me.

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Re: Linux CAN CUSE hacks, SocketCAN and RT Was: adding can4linux to drivers/char

[Pavel Pisa]

Hello All,

I monitor this discussion for longer time.
Unfortuantelly I am quite out of time and we need some more
testing of newer kernels with SocketCAN and some alternatives
to backup my observations. But I cannot stay longer silent.

On Tuesday 01 of October 2013 22:20:55 May, Stefan wrote:
> > And add a CUSE adaption for your legacy costumers.
>
> CUSE adaption is not possible in the case of can4linux API. I tried that
> once and failed. The reason is in read() and write() call where can4linux
> chooses to use the number of frames instead of bytes for the count
> parameter.

Such choice is broken by design and I would beg and protest against
inclusion of such thing into mainline. This is against POSIX
read/write calls definitions. This breaks all tools like Valgrind
and security checks etc. You can do so such weird things on Linux
but under Windows KDM and WDM models with IRP packets you cannot.
Same in many sane systems either. It breaks possible future modifications
of Linux to the more microkernel/hypervisor based design etc.
(and yes, I am aware that there is/was similar brokenness in mainline
kernel already somewhere in I2C code where read uses address provided
in the first byte of buff which should be receive only, but at least
size matches).

On Wednesday 02 of October 2013 09:49:12 Oliver Hartkopp wrote:
> Btw. CUSE is open source.
> Why not adding a feature to CUSE that allows to pass the number of structs
> instead of the number of bytes?

Please no, NO, I expect that CUSE maintainers would cry loud as well.

Lack of in and out size arguments for IOCTL in POSIX standard
is enough disaster for now. That is one of (hopefully) not so
many things which are better on Windows and cannot be corrected
ON Linux without standard breakage. When suggested IOCL values
construction is used then it IS not so horrible for usual cases.

On the other hand, there is really only limited space for CUSE
use when we speak about CAN and real CAN applications targetting
control and real real-time applications. There would be even
additional overhead added to the SocketCAN.

And there are legal demand for Linux CAN support suitable
for real real-time/(near)hard real-time applications. SocketCAN
has very nice API, but its overhead and Linux networking
stack problems with RT-kernel are significant obstacles,
at least according our long time testing.

We (mainly my colleague Michal Sojka and this year even
Martin Horenovsky - student paid from our group budget over holidays)
have spent significant time on Linux CAN system testing and measurement.
This year round is not finished and interpretation is missing still.
We have intended to announce that after some analysis is finished
but to have some clue for possible future discussion, there are
actual results

  http://rtime.felk.cvut.cz/can/benchmark/3.0/

Even simple/not-tuned RTEMS system driver was added to the
test (per journal article reviewer request to compare against
other system). And it latencies are much much better than
SocketCAN or any RT kernel (we need to find time for update/porting/testing
latest ones but that is not so easy - 3.6.x-rt and around were
totally unusable on our HW). RT usability indicator "nop-highprio"
test breaks many RT kernels when Etherned load is applied and results
are not so great even for these which work

http://rtime.felk.cvut.cz/can/benchmark/3.0/host-2.6.36.2-00015-g4f1bc4e/2.6.33.7-rt29-00004-g92487e4/flood/eth/nop-highprio/results.html

Compare Linux results with RTEMS

http://rtime.felk.cvut.cz/can/benchmark/3.0/host-2.6.36.2-00015-g4f1bc4e/rtems4.10-midam/flood/eth/nop-highprio/results.html

The comparison is not fair to Linux, RTEMS driver is really much simpler
and no GW functionality or other SocketCAN/Linux advantages are present.
"GW" is only simple copy from one CAN interface to another through open,
read and write calls in standard application, but RTEMS has no 
userspace/kernelspace call overhead (it uses same memory context
and no protection in our case). But it illustrates bare
HW capabilities.

I have more things and thought to say but I am not fully ready
for that and I have fear that required amount of work is above
my time and knowledge so most of my thoughts are more or less
grumbles.

Best wishes,

                Pavel

Re: Linux CAN CUSE hacks, SocketCAN and RT Was: adding can4linux to drivers/char

[Wolfgang Grandegger]

On Wed, 2 Oct 2013 10:43:59 +0200, Pavel Pisa <pisa@cmp.felk.cvut.cz>

wrote:

> Hello All,

> 

> I monitor this discussion for longer time.

> Unfortuantelly I am quite out of time and we need some more

> testing of newer kernels with SocketCAN and some alternatives

> to backup my observations. But I cannot stay longer silent.

> 

> On Tuesday 01 of October 2013 22:20:55 May, Stefan wrote:

>> > And add a CUSE adaption for your legacy costumers.

>>

>> CUSE adaption is not possible in the case of can4linux API. I tried

that

>> once and failed. The reason is in read() and write() call where

can4linux

>> chooses to use the number of frames instead of bytes for the count

>> parameter.

> 

> Such choice is broken by design and I would beg and protest against

> inclusion of such thing into mainline. This is against POSIX

> read/write calls definitions. This breaks all tools like Valgrind

> and security checks etc. You can do so such weird things on Linux

> but under Windows KDM and WDM models with IRP packets you cannot.

> Same in many sane systems either. It breaks possible future

modifications

> of Linux to the more microkernel/hypervisor based design etc.

> (and yes, I am aware that there is/was similar brokenness in mainline

> kernel already somewhere in I2C code where read uses address provided

> in the first byte of buff which should be receive only, but at least

> size matches).

> 

> On Wednesday 02 of October 2013 09:49:12 Oliver Hartkopp wrote:

>> Btw. CUSE is open source.

>> Why not adding a feature to CUSE that allows to pass the number of

>> structs

>> instead of the number of bytes?

> 

> Please no, NO, I expect that CUSE maintainers would cry loud as well.



Yep and such a read/write implementation for a character device would

also not have any chance to be included in the mainline kernel.



Wolfgang.