netdev - Re: [net-next v3 14/15] iecm: Add iecm to the kernel build system

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: <f8b49d7e88a0e5016a16a03dd50b28e73c2a49cc.camel@perches.com>
Date:   Thu, 25 Jun 2020 20:32:05 -0700
From:   Joe Perches <joe@...ches.com>
To:     Jeff Kirsher <jeffrey.t.kirsher@...el.com>, davem@...emloft.net
Cc:     Alice Michael <alice.michael@...el.com>, netdev@...r.kernel.org,
        nhorman@...hat.com, sassmann@...hat.com,
        Alan Brady <alan.brady@...el.com>,
        Phani Burra <phani.r.burra@...el.com>,
        Joshua Hay <joshua.a.hay@...el.com>,
        Madhu Chittim <madhu.chittim@...el.com>,
        Pavan Kumar Linga <pavan.kumar.linga@...el.com>,
        Donald Skidmore <donald.c.skidmore@...el.com>,
        Jesse Brandeburg <jesse.brandeburg@...el.com>,
        Sridhar Samudrala <sridhar.samudrala@...el.com>
Subject: Re: [net-next v3 14/15] iecm: Add iecm to the kernel build system

On Thu, 2020-06-25 at 19:07 -0700, Jeff Kirsher wrote:
> From: Alice Michael <alice.michael@...el.com>
[]
> diff --git a/Documentation/networking/device_drivers/intel/iecm.rst b/Documentation/networking/device_drivers/intel/iecm.rst
[]
> @@ -0,0 +1,93 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +========================
> +Intel Ethernet Common Module
> +========================
> +
> +The Intel Ethernet Common Module is meant to serve as an abstraction layer
> +between device specific implementation details and common net device driver
> +flows. This library provides several function hooks which allow a device driver
> +to specify register addresses, control queue communications, and other device
> +specific functionality.  Some functions are required to be implemented while
> +others have a default implementation that is used when none is supplied by the
> +device driver.  Doing this, a device driver can be written to take advantage
> +of existing code while also giving the flexibility to implement device specific
> +features.
> +
> +The common use case for this library is for a network device driver that wants

to

> +specify its own device specific details but also leverage the more common
> +code flows found in network device drivers.