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 
<> Date: 2/11/20  9:48 AM  (GMT-06:00) To: 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     
(sched/), memory manager    ||(mm/), common libraries 
      Hardware            |+-------------------------------+

Reply via email to