The requirements from Pavel are inconsistent with the current character driver.
Certainly it could be possible to use a common backend, but I suspect it would
be simpler not to.Sent from my Samsung Galaxy smartphone.
-------- Original message --------From: Peter Van Der Perk
<peter.vanderp...@nxp.com> Date: 2/11/20 9:48 AM (GMT-06:00) To:
dev@nuttx.apache.org Subject: RE: Re: NuttX SocketCAN implementation >I believe
that both sides would be the same. Both would use BSD sockets, SocketCAN would
be added to the network stacks, and the CAN drivers would be a network
drivers.>>Your picture shows the existing implementation using character
drivers.>SocketCAN is intended to be integrated into the network.Thanks for the
quick response, indeed you're right the CAN drivers would become network
drivers and in the BSD sockets layer we can add the PF_CAN protocol. However my
question is then, would there still be a need for need for CAN using character
drivers (and userspace api)? If so, do we have to make 2 separate HW drivers,
one for CAN using character devices and one for CAN using SocketCAN? Or does
the current infrastructure support both? The reason why I'm asking this is to
think about trade-offs between compatibility, realtime performance and
maintainability.>I amn't familiar with CAN, but is it possible to implement a
general CAN MAC driver on top of CAN CHAR driver like
this?>+-------------------------------+>| NuttX Network driver |>|
+------------+ +------------+ |>| |Syscall glue| |BSD Socket | |>| |
| |glue | |>| +------------+ +------------+
|>+-------------------------------+>+-------------------------------+ file_*
+-------------------------------+>| Hardware MAC driver |---------->|
NuttX CAN Driver (can.c) |>+-------------------------------+ |
+------------+ >+-------------------------------+ +------------+ |>
| |Syscall glue| |Char driver | |>
| | | |glue | |>
| +------------+ +------------+ |>
+-------------------------------+>
+-------------------------------+>
| Hardware CAN driver |>
+-------------------------------+ So we just need write one
CAN driver, but the user can select socket or char as they want.From
ease-of-implementation perspective that would be the way to go. However this
would mean that a CAN frame would go through the CAN driver -> Char driver ->
VFS -> Socket -> user space. This would add unnecessary delay and jitter which
would be certainly worse. Ideally I would implement it as shown below. The
question is though then how do deal with existing CAN character device
implementation? NuttX SocketCAN implementation
Proposal+-------------------------------+| Application
|+-------------------------------++-------------------------------+|
POSIX Interface |+-------------------------------++-------------+
+-------------+|System calls | |BSD socket || | |net/sockets
|+-------------+ +-------------++-------------------------------+| NuttX
Network driver || +------------+ +------------+ || |Syscall glue| |BSD
Socket | || | | |glue PF_CAN| || +------------+ +------------+
|+-------------------------------++-------------------------------+| NEW
Hardware CAN driver
|+-------------------------------++-------------------------------+|OS
(sched/), memory manager ||(mm/), common libraries
(libs/)|+-------------------------------++-------------------------------+|
Hardware |+-------------------------------+
