Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 1 Aug 2018 07:52:12 -0600
From:   Jonathan Corbet <corbet@lwn.net>
To:     "Tobin C. Harding" <me@tobin.cc>
Cc:     Daniel Borkmann <daniel@iogearbox.net>,
        Alexei Starovoitov <ast@kernel.org>,
        "David S. Miller" <davem@davemloft.net>, linux-doc@vger.kernel.org,
        netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf-next 03/13] docs: net: Add filter to index toctree
Message-ID: <20180801075212.6e42fa0c@lwn.net>
In-Reply-To: <20180801050908.29970-4-me@tobin.cc>
References: <20180801050908.29970-1-me@tobin.cc>
        <20180801050908.29970-4-me@tobin.cc>
Organization: LWN.net
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed,  1 Aug 2018 15:08:58 +1000
"Tobin C. Harding" <me@tobin.cc> wrote:

> filter.rst was just created (from filter.txt).  We should include it in
> the networking docs toctree.
> 
> Add filter to Documentation/networking/index.rst toctree.

So...the minorest of nits just to prove that I actually looked at
this...:)  Adding it to the toctree at this point is going to make the
docs build messy (OK, even messier than it already is) because the RST
conversion hasn't really been done yet.  I'd do this at the end of the
series, just in case somebody, somewhere, is crazy enough to try to
bisect a docs build.

Something that's a bit more relevant, perhaps: this document is a bit of
a mishmash.  It starts by talking about how to use cBPF for socket
filters, then includes a long discussion about the features of eBPF
which, as I understand it, is still not accessible to user space for
socket filters. That latter part certainly merits being in its own file
where people will actually find it?  And if it were me, I would move that
file into the core API guide, since it will be relevant beyond networking.

Thanks,

jon