On Tue, Feb 11, 2020 at 11:48 PM Peter Van Der Perk
<[email protected]> 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 |
> +-------------------------------+
>
>
>
