Re: Re: NuttX SocketCAN implementation

[Xiang Xiao]

On Tue, Feb 11, 2020 at 11:48 PM Peter Van Der Perk
 wrote:
>
> >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?
>

The performance may not bad as your thinking: all kernel side VFS
functions(file_*)  simplely forward to the function pointers inside
file_operations, so the real sequence is:
CAN MAC 
driver->file_*(fs/vfs)->file_operations->*(drivers/can/can.c)->can_ops_s(CAN
lowhalf driver)
If the performance is still unacceptable, we can bypass VFS and
implement CAN MAC driver directly on top of can_ops_s:
CAN MAC driver->can_ops_s(CAN lowhalf driver)
Then we can reuse all CAN low half drivers without change, and the
user can even select BSD socket or VFS char like this:
#ifdef CONFIG_CAN_SOCKET
can_mac_register(&g_can_dev);
#else
can_register("dev/can0", &g_can_dev);
#endif

Thanks
Xiang
>
>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|
> +---+
>
>
>

RE: Re: NuttX SocketCAN implementation

[Peter Van Der Perk]

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

I will look into making a SocketCAN proof-of-concept based on the architecture 
shown in the picture above. If there are any suggestions or questions please 
don't hesitate to contact me or reply in this thread.

RE: Re: NuttX SocketCAN implementation

[spudaneco]

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: 
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    |+---+

RE: Re: NuttX SocketCAN implementation

[Peter Van Der Perk]

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