[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AE90C24D6B3A694183C094C60CF0A2F6026B7480@saturn3.aculab.com>
Date: Wed, 11 Dec 2013 13:19:21 -0000
From: "David Laight" <David.Laight@...LAB.COM>
To: "Atzm Watanabe" <atzm@...atosphere.co.jp>
Cc: <netdev@...r.kernel.org>,
"Stephen Hemminger" <stephen@...workplumber.org>,
"Ben Hutchings" <bhutchings@...arflare.com>,
"David Miller" <davem@...emloft.net>,
"Daniel Borkmann" <dborkman@...hat.com>
Subject: RE: [PATCH v2] packet: Deliver VLAN TPID to userspace
> From: Atzm Watanabe
...
> > You've defined a new header variant, but all the code seems to rely
> > on the fact that the 'new' variant is identical to the old one
> > with the addition of an extra field at the end.
> >
> > In which case it ought to be valid to just extend the old header variant.
> > If the header really can change format there ought to be a discriminating
> > member somewhere - which you don't seem to have changed.
>
> Yes. I think that struct tpacket3_hdr can grow safely until 48 bytes,
> so I'd just like to extend tpacket_hdr_variant1 like you said.
>
> But in the past discussions, there were mentions that a new member
> cannot be added into struct tpacket_hdr_variant1, and possibly the
> variant which includes a new member should be separated from the old
> one.
>
> http://patchwork.ozlabs.org/patch/284671/
> http://patchwork.ozlabs.org/patch/285382/
I don't remember it being mentioned earlier that there are pad bytes
following the header.
Might be worth explicitly defining the pad bytes and zeroing them.
That could make additional changes easier.
David
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists