netdev - Re: [net-next PATCH 0/4] Documenting eBPF - extended Berkeley Packet Filter

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: <20170207142323.67f08f47@lwn.net>
Date:   Tue, 7 Feb 2017 14:23:23 -0700
From:   Jonathan Corbet <corbet@....net>
To:     Jesper Dangaard Brouer <brouer@...hat.com>
Cc:     netdev@...r.kernel.org, linux-doc@...r.kernel.org,
        Alexei Starovoitov <ast@...com>, alexander@...mayhu.com,
        linux-kernel@...r.kernel.org, quentin.monnet@...nd.com,
        Daniel Borkmann <borkmann@...earbox.net>
Subject: Re: [net-next PATCH 0/4] Documenting eBPF - extended Berkeley
 Packet Filter

On Tue, 7 Feb 2017 21:51:49 +0100
Jesper Dangaard Brouer <brouer@...hat.com> wrote:

> I sounds like Daniel (see other email) have bigger plans for what
> Documentation/BPF/ should contain.  E.g. consolidating
> Documentation/networking/filter.txt which covers the cBPF/eBPF internals.
> If that is the case (and I like the idea), then it goes beyond a
> "userspace-guide".  And perhaps "BPF" is a "book" of its own?

One of the real problems with the kernel's documentation is that there is
really almost no thought given to who the audience is.  We have docs for
kernel developers, for system admins, for user-space developers, etc., and
it's all mixed up into one big jumble.

An objective of mine in launching into this whole project is to try to fix
that, so that people can readily find the documentation they need.  So I
don't think a single top-level directory, with a mix of user-space API
info and "internals", is the right direction to go.  The internals docs
should, IMO, go elsewhere, probably in the core-api manual.

See what I'm getting at here?

> And it seems Daniel is proposing capital-letters BPF for the directory
> name "Documentation/BPF/"?  Any opinions on that? (I'm neutral)

I think we should paint it green; otherwise I'm not too concerned about
this particular point...:)

Thanks,

jon