Thanks for all the participation and feedback. Here is my attempt at a
summary of what we have discussed so far:
- Common goal: A solid LIN UAPI and API
- LIN fits CAN well and could be embedded into Linux CAN infrastructure
- LIN support cannot be a tty-line-discipline driver for all devices
out there
- slLIN should become a user of this API
- slLIN itself needs some more options in the line-discipline
configuraion (to tweak UART FIFO settings and e.g. enable
LIN-break-detection for supported UARTs) _or_ tty-LIN support
becomes something more like RS485 and get integrated into
tty-drivers directly.
- LIN devices with off loading capabilities are a bit special.
- one approach is to have a kfifo for the slavetable (64 entries a 8
bytes + checksum and some extra flags for some LIN special cases)
while updating it from userland through CAN or a simple sysfs
interface
- when we agree that "dumb" UARTs have no need for an
in-kernel-off-load slavetable (because of RT-Linux), then there
are only devices left (e.g. some USB adapters) maintaining their
own table, so a simple e.g. sysfs update mechanism would be
enough (without the need for an in-kernel kfifo buffer).
- LIN slavetable might need another name
- LIN needs rx, tx, set bitrate, set checksum variant and maybe update
a slavetable (or whatever it is called then...)
What do you think? Any objections, corrections, enhancements?
My question is: Which approach of an API is favored: Patch 1 or 2 of
this RFC series or something completely different?
Thanks
-- Christoph
