On Thu, 2009-07-16 at 13:10 -0700, Peter Memishian wrote: > > > I'm not following. How does that resolve issues with interacting with > > > locking inside IP proper? > > > > The functions called perform their own locking to access and modify the > > classifier, or to access IRE tables, for example. The usage is really > > no different than udp.c's (e.g. udp_do_bind()) or tcp.c's (e.g. > > tcp_connect_ipv4()). Perhaps I can talk with Thiru to have him clue me > > in on what potential issues are going to broadside this design (or > > better yet, have him code-review those sections of the iptun module). > > My point is that different entrypoints in IP have massively different > requirements -- e.g., clearly you cannot call any functions that require > being writer on an IPSQ from outside of IP without a lot of special code. > If all of the functions you're accessing in IP have no requirements on > caller context or locks held on internal IP data structures, then there's > no issue -- but it would be worth calling out (the design document didn't > make this clear to me). Further, at an abstract level the IP functions > called by the tun module are significant to the architecture of the > component since they clarify the coupling and expectations between the two > modules.
That's a fair request. I'll add details on what ip functions are used and why. -Seb
