Netdev Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Willem de Bruijn <email@example.com>
To: Xie He <firstname.lastname@example.org>
Cc: Willem de Bruijn <email@example.com>,
"David S. Miller" <firstname.lastname@example.org>,
Jakub Kicinski <email@example.com>,
John Ogness <firstname.lastname@example.org>,
Eric Dumazet <email@example.com>,
Or Cohen <firstname.lastname@example.org>,
Arnd Bergmann <email@example.com>,
Network Development <firstname.lastname@example.org>,
Eric Dumazet <email@example.com>,
Brian Norris <firstname.lastname@example.org>,
Cong Wang <email@example.com>
Subject: Re: [PATCH net] net/packet: Fix a comment about hard_header_len and headroom allocation
Date: Tue, 8 Sep 2020 15:55:54 +0200 [thread overview]
Message-ID: <CA+FuTSdGXF-gxEvfOxZd1dNXfBmaDKFqGTH8EzNXZpYLcrwzjA@mail.gmail.com> (raw)
> > > > More about the older comment, but if reusing: it's not entirely clear
> > > > to me what "outside of the device" means. The upper layers that
> > > > receive data from the device and send data to it, including
> > > > packet_snd, I suppose? Not the lower layers, clearly. Maybe that can
> > > > be more specific.
> > >
> > > Yes, right. If a header is visible "outside of the device", it means
> > > the header is exposed to upper layers via "header_ops". If a header is
> > > not visible "outside of the device" and is only used "internally", it
> > > means the header is not exposed to upper layers via "header_ops".
> > > Maybe we can change it to "outside of the device driver"? We can
> > > borrow the idea of encapsulation in object-oriented programming - some
> > > things that happen inside a software component should not be visible
> > > outside of that software component.
> > How about "above"? If sketched as a network stack diagram, the code
> > paths and devices below the (possibly tunnel) device do see packets
> > with link layer header.
> OK. I understand what you mean now. We need to make it clear that the
> header is only invisible to upper layers but not to "lower layers"
> that the device may rely on.
> I'm thinking about a way to clearly phrase this. "Above the device"
> might be confusing to people. Do you think this is good: "invisible to
> upper-layer code including the code in af_packet.c"? Or simply
> "invisible to upper-layer code"? Or just "invisible to upper layers"?
> (I don't like the last one because I feel according to the network
> stack diagram "upper layers" should already and always not care about
> the LL header.)
Upper layers is often understood to imply the network stack diagram
indeed, excluding other stacks, such as virtual devices or packet
sockets. Hence above. But either works. The commit message will
prev parent reply other threads:[~2020-09-08 16:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-06 3:18 Xie He
2020-09-07 9:40 ` Willem de Bruijn
2020-09-08 0:07 ` Xie He
2020-09-08 8:55 ` Willem de Bruijn
2020-09-08 11:27 ` Xie He
2020-09-08 13:55 ` Willem de Bruijn [this message]
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [PATCH net] net/packet: Fix a comment about hard_header_len and headroom allocation' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).