> Proposal 1: implement the equivalent of eth_type_trans(skb, dev) for the
> syncppp devices.
Ok
> Proposal 2: implement the common device allocation & registration code
> similar to the init_etherdev() and ether_setup() routines.
Ok
> is set to ETH_P_WAN_PPP, the packet is passed to netif_rx(),
> and the sppp_input() routine then changes the skb->type
> to the appropriate 3rd-layer protocol (IP or IPX)
> and passes the skb to netif_rx() once again. This is wrong and it
> caused misinterpretation in tcpdump and ipchains in the past (the packet
> is seen twice by the network stack). LCP or Cisco keepalive
> packets are handled directly (and thus are seen only once).
We can handle them directly. What we cannot do however is handle them directly
in netif_rx() . The syncppp processing overhead is too high to put in the IRQ
path of the Z85230.
> have the sppp_type_trans(skb, dev) routine for setting up the
> skb->proto, skb->mac.raw, and maybe skb->dev fields. It should
> immediately decide between the ETH_P_IP, ETH_P_IPX and assign
(Syncppp should be using the generic ppp layer in 2.3.x)
> I propose to implement the init_spppdev(dev, sizeof_priv) routine,
> which will allocate the struct net_device (if needed) and all the
> other structures, sets up the syncppp device part (struct ppp_device)
> and initialize the syncppp layer using sppp_attach() (which seems
> to be a good equivalent of ether_setup()).
Ok
> (and add something like ETH_P_CISCO for Cisco HDLC keepalive
> and other frames)? Or should I use ETH_P_WAN_PPP type for both
> Cisco HDLC service frames and PPP (LCP/IPCP/keepalive) ones?
Add an ETH_P_CHDLC I think
> Alternatively, the sppp_input can be called instead of netif_rx()
> by the network driver, but I think it causess too much work to be
> done at the (possible) interrupt time.
It causes too much work - I tried it originally. The 85230 is very very
time sensitive as its a paticularly stupid chip and people insist on running
it at 512Kbit.
> are static. We can add the init_spppdev() into net_init.c, but this
> routine should call sppp_attach, which will need the syncppp.c
> to be linked into the kernel (possibly with new CONFIG_SYNCPPP
> option, which would be set if CONFIG_COSA or CONFIG_HOSTESS or
> CONFIG_SEALEVEL is set).
Just make them non static. They are static because nobody needed them
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:21 EST