Messages in this thread | | | Date | Thu, 8 Jul 1999 05:36:57 +0200 | From | Andi Kleen <> | Subject | Re: Synchronous board drivers |
| |
On Wed, Jul 07, 1999 at 10:16:04PM +0200, Henner Eisen wrote: > >>>>> Andi Kleen <ak@muc.de> writes: > > >> interface. The disadvantage is that it does not allow to pass > >> link state changes (i.e. tty hangup) to the upper layer and > >> that each packet passes netif_rx two times. > > > You can use skb->cb[] to pass lots of state. IP/TCP need it too > > for sending, on the receiving side it is free for use until it > > hits ip_rcv. Just make sure that all drivers who use the > > protocol type know about it. > > > -Andi > > Who is the official `owner' of the skb->cb field? Is it a public field of > the sk_buff structure or is it subject to removal if somebody > re-designs tcp/ip?
The official owner is the layer where the skb passes through.
> It seems, we need to be careful if the packet passed multiple netif_rx() > E.g. if the hdlc device passes the frame upstream by a netif_rx(), devlivers > it to syncppp_rcv() which finally passes it further upstream by a > second netif_rx(). Further, if tcp/ip uses the cb field, the cb field > cannot be used in a symmetrical manner to pass link control information > downstream to the device.
It is free because TCP is carefull to skb_clone() first.
[This all applies to 2.2, in 2.0 this is not guaranteed]
It doesn't work for multiple netif_rx(), correct, because then you lose your current layer context.
> > Would a new packet type like PACKET_CONTROL would be appropriate?
Oh no, please no STREAMS.
> (Anyway, it seems that ppp can get along without as all link state related > stuff can be entirely hadled by pppd without the need of enhancing > kernel-internal interfaces).
That sounds good.
-Andi (who still hopes isdn4linux will someday do connection management in user space) -- This is like TV. I don't like TV.
- 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/
| |