On Wed, Oct 01, 2008 at 04:08:39PM -0400, bfields wrote: > On Wed, Oct 01, 2008 at 03:40:05PM -0400, Chuck Lever wrote: > > On Oct 1, 2008, at Oct 1, 2008, 2:18 PM, J. Bruce Fields wrote: > >> On Wed, Oct 01, 2008 at 12:17:02PM -0400, Chuck Lever wrote: > >>> On Sep 26, 2008, at Sep 26, 2008, 7:09 PM, J. Bruce Fields wrote: > >>>> On Wed, Sep 17, 2008 at 11:18:11AM -0500, Chuck Lever wrote: > >>>>> The XDR decoders for the NSM NOTIFY procedure should construct a > >>>>> full > >>>>> socket address and store it in the nlm_reboot structure. In > >>>>> addition > >>>>> to being able to store larger addresses, this means upper layer > >>>>> routines get an address family tag so they can distinguish between > >>>>> AF_INET and AF_INET6 addresses. > >>>>> > >>>>> This also keeps potentially large socket addresses off the stack > >>>>> and > >>>>> instead in dynamically allocated storage. > >>>> > >>>> So one way to think of this would be that you're extending the > >>>> kernel<->statd interface by using the address family of statd's > >>>> notify > >>>> call to communicate the address family of the host that rebooted. > >>>> > >>>> Do I have that right? > >>> > >>> For statd, we're using the same technique that we used when > >>> constructing > >>> the source address in nlmsvc_lookup_host(). There's no family tag > >>> associated with the address because the 16-byte opaque in the on- > >>> the-wire > >>> format has room only for the sin6_addr part of the address. > >> > >> OK. It seems a bit tricky, but I can't see why it doesn't work. > > > > Right. I couldn't think of something simpler. > > > > rpc.statd has to continue to work with legacy kernels where the first 4 > > bytes of the opaque are a 32-bit sin_addr field and the following 12 > > bytes are zero. > > Wait a minute, there's something not right there: rpc.statd shouldn't > interpret the contents of the opaque field at all, should it? And from a quick look at nfs-utils/statd/ it certainly looks to me like it's correctly treating the contents as a totally opaque object. So I think we can put whatever we want in the priv field--an ipv6 address, an index into some kernel table, whatever. (The priv field shouldn't even have to make sense to a future boot instance--we don't need to be notified of previously monitored hosts' reboots any more once we've rebooted ourselves.) --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
