netdev - 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]

Date:   Mon, 28 Nov 2022 23:47:56 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Christoph Fritz <christoph.fritz@...dev.de>
Cc:     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>,
        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

>   - LIN devices with off loading capabilities are a bit special.

For networking in general, we try very hard to make offload to
hardware not special at all. It should just transparently work.

One example of this is Ethernet switches which Linux controls. The
ports of the switch are just normal Linux interfaces. You can put an
IP address onto the ports in the normal way, you can add a port to a
linux bridge in the normal way. If the switch can perform bridging in
hardware, the linux bridge will offload it to the hardware. But for
the user, its just a port added to a bridge, nothing special. And
there are a lot more examples like this.

I don't know CAN at all, but please try to avoid doing anything
special for hardware offload. We don't want one way for software, and
then 42 different ways for 42 different offload engines. Just one uAPI
which works for everything.

    Andrew