Thread (35 messages) 35 messages, 7 authors, 2006-07-08

Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch

From: "David S. Miller" <davem@davemloft.net>
Date: 2006-05-04 23:11:58

From: Kelly Daly <redacted>
Date: Thu, 4 May 2006 17:28:27 +1000
On Wednesday 26 April 2006 17:59, David S. Miller wrote:
quoted
Next, you can't even begin to work on the protocol channels before you
do one very important piece of work.  Integration of all of the ipv4
and ipv6 protocol hash tables into a central code, it's a total
prerequisite.  Then you modify things to use a generic
inet_{,listen_}lookup() or inet6_{,listen_}lookup() that takes a
protocol number as well as saddr/daddr/sport/dport and searches
from a central table.
Back here again  ;)

Is this on the right track (see patch below)?
It is on the right track.

I very much fear abuse of the inet_hashes[] array.  So I'd rather
hide it behind a programmatic interface, something like:

extern struct sock *inet_lookup_proto(u16 protocol, u32 saddr, u16 sport,
				      u32 daddr, u16 dport, int ifindex);

and export that from inet_hashtables.c

Then you have registry and unregistry functions in inet_hashtables.c
that setup the static inet_hashes[] array.  So TCP would go:

	inet_hash_register(IPPROTO_TCP, &tcp_hashinfo);

instead of the direct assignment to inet_hashes[] it makes right
now in your patch.

Thanks!
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help