From owner-freebsd-net Wed Mar 21 18:19: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 423C937B71A for ; Wed, 21 Mar 2001 18:18:57 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id VAA24617; Wed, 21 Mar 2001 21:18:28 -0500 (EST) (envelope-from wollman) Date: Wed, 21 Mar 2001 21:18:28 -0500 (EST) From: Garrett Wollman Message-Id: <200103220218.VAA24617@khavrinen.lcs.mit.edu> To: "Geoffrey Crompton (RMIT Guest)" Cc: FreeBSD-Net Subject: how dies rtallocing with XResolve happen In-Reply-To: <20010322115354.A28374@gecko.eric.net.au> References: <20010322115354.A28374@gecko.eric.net.au> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > What is the goal of the XRESOLVE mechanism. Is it to allow code in the > kernel to inform a userland daemon that a routing lookup was performed > and it failed, or is it to allow code in the kernel to have a userland > daemon resolve a route for it? Yes. > If it is the second, how does the userland daemon get an answer back > to the kernel, considering that the userland daemon may need to do some > network communication to get an answer? Well, obviously, it can't communicate with anything that would need the route that it's trying to resolve. That doesn't stop it from communicating with other (perhaps statically-configured) end systems. I believe it was actually intended for things like the X.25 code, where conceivably one might have to look up the X.121 (IIRC) address for the system you are trying to reach in a text file somewhere, or by sending a request to some well-known server. Often that sort of code is so klugey that you don't want it in the kernel. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message