linux-kernel - Re: [RFC][PATCH 0/2] LIN support for Linux

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y4UslxhfRPVGXzS/@mars>
Date:   Mon, 28 Nov 2022 22:48:07 +0100
From:   Christoph Fritz <christoph.fritz@...dev.de>
To:     Ryan Edwards <ryan.edwards@...il.com>,
        Oliver Hartkopp <socketcan@...tkopp.net>,
        Pavel Pisa <pisa@....felk.cvut.cz>,
        Andreas Lauser <andreas.lauser@...tion.io>,
        Richard Weinberger <richard@....at>,
        Wolfgang Grandegger <wg@...ndegger.com>,
        Marc Kleine-Budde <mkl@...gutronix.de>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>
Cc:     Jonathan Corbet <corbet@....net>, linux-can@...r.kernel.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH 0/2] LIN support for Linux

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