From owner-freebsd-arch@FreeBSD.ORG Mon Apr 6 15:50:18 2009 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A876110656D9; Mon, 6 Apr 2009 15:50:18 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from gigi.cs.uoguelph.ca (gigi.cs.uoguelph.ca [131.104.94.210]) by mx1.freebsd.org (Postfix) with ESMTP id 63B908FC08; Mon, 6 Apr 2009 15:50:18 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by gigi.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id n36FoDOK014419; Mon, 6 Apr 2009 11:50:13 -0400 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n36FuK024013; Mon, 6 Apr 2009 11:56:20 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 6 Apr 2009 11:56:20 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Robert Watson In-Reply-To: Message-ID: References: <49D98461.4000002@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.63 on 131.104.94.210 Cc: Julian Elischer , freebsd-arch@FreeBSD.org Subject: Re: getting a callback ip address for nfsv4 client X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 15:50:18 -0000 On Mon, 6 Apr 2009, Robert Watson wrote: > On Sun, 5 Apr 2009, Julian Elischer wrote: > >>> One possibility is to connect() a socket to the server address, then call >>> getsockaddr() to query what address the network stack is using. If the >>> connection completed, then the address could at least send packets to the >>> server, even if it isn't reachable from the server. >>> >>> (Obviously, kernel versions of the above...) >> >> we ended up with him doing "whatever the connect code would have done" >> since as he is in fact inside the kernel, he can just do the same.. > > I figured that if the RPC layer was going to make a connection anyway, we > could just query the RPC layer and ask it what address it had used. However, > if the decision needs to be made earlier than that, then that doesn't make as > much sense. This would mean NFS could avoid knowing about routes and > interfaces, and just know about sockets and addresses. > I just took a quick look at Doug's RPC code and the socket doesn't seem to be exposed to the client side by the rpc layer, so I think that rtalloc1() is probably easier? I'd also be worried about knowing when the socket pointer is valid and in a connected state. (The rtalloc1() code only uses the one path rt->rt_ifa->ifa_addr after sanity checking that the pointers aren't null, so I don't think it will be difficult to maintain. It does imply that the code knows the route locking rules, but that just means it uses RTFREE_LOCKED(rt), so as long as that macro keeps working, it should be ok, I think.) rick