On Thu, Oct 29, 2020 at 8:49 PM Xie He wrote:
>
> On Thu, Oct 29, 2020 at 4:53 PM Xie He wrote:
> >
> > > Does it make sense to define a struct snap_hdr instead of manually
> > > casting all these bytes?
> >
> > > And macros or constant integers to self document these kinds of fields.
> >
> >
On Thu, Oct 29, 2020 at 7:53 PM Xie He wrote:
>
> On Thu, Oct 29, 2020 at 10:24 AM Willem de Bruijn
> wrote:
> >
> > > Also add skb_reset_mac_header before we pass an skb (received on normal
> > > PVC devices) to upper layers. Because we don't use header_ops for normal
> > > PVC devices, we
On Thu, Oct 29, 2020 at 4:53 PM Xie He wrote:
>
> > Does it make sense to define a struct snap_hdr instead of manually
> > casting all these bytes?
>
> > And macros or constant integers to self document these kinds of fields.
>
> Yes, we can define a struct snap_hdr, like this:
>
> struct
On Thu, Oct 29, 2020 at 10:24 AM Willem de Bruijn
wrote:
>
> > Also add skb_reset_mac_header before we pass an skb (received on normal
> > PVC devices) to upper layers. Because we don't use header_ops for normal
> > PVC devices, we should hide the header from upper layer code in this case.
>
>
On Wed, Oct 28, 2020 at 6:58 PM Xie He wrote:
>
> Change the fr_rx function to make this driver support any Ethertype
> when receiving skbs on normal (non-Ethernet-emulating) PVC devices.
> (This driver is already able to handle any Ethertype when sending.)
>
> Originally in the fr_rx function,
Change the fr_rx function to make this driver support any Ethertype
when receiving skbs on normal (non-Ethernet-emulating) PVC devices.
(This driver is already able to handle any Ethertype when sending.)
Originally in the fr_rx function, the code that parses the long (10-byte)
header only
6 matches
Mail list logo
