On Tue, 2008-06-17 at 17:36 -0400, J. Bruce Fields wrote: > On Mon, Jun 16, 2008 at 10:28:59AM -0400, Jeff Layton wrote: > > On Fri, 13 Jun 2008 18:50:37 -0400 > > "J. Bruce Fields" <bfields@xxxxxxxxxxxxxx> wrote: > > > > > The client needs a new more estensible text-based upcall to gssd, to > > > make it easier to support some features that are needed for new krb5 > > > enctypes, for callbacks, etc. > > > > > > We will have to continue to support the old upcall for backwards > > > compatibility with older gssd's. To simplify upgrades, as well as > > > testing and debugging, it would help if we can upgrade gssd without > > > having to choose at boot (or module-load) time whether we want the new > > > or the old upcall. > > > > > > That means that when gssd opens an rpc upcall pipe, we'd like to just > > > start using whichever version it chose immediately--ideally without > > > having to wait the 30 seconds that it would normally take for upcalls > > > already queued on the wrong upcall pipe to time out. > > > > > > The following patches do that by queueing the upcalls on whichever of > > > the two upcall pipes (the new one and the old one) that somebody holds > > > open. If nobody's opened anything yet, then upcalls are provisionally > > > queued on the new pipe. I add a pipe_open method to allow the gss code > > > to keep track of which pipe is open, to prevent anyone from attempting > > > to open both pipes at once, and to cancel any upcalls that got queued to > > > the wrong pipe. > > > > > > I did some minimal testing with the old upcall, but haven't tested the > > > new upcall yet. (Olga, could you do that?) So this is just an RFC at > > > this point. > > > > > > --b. > > > > Has any thought been given to moving all of the rpc_pipefs upcalls to use > > the keyctl API that David Howells did? It seems like that would be better > > suited to this sort of application than rpc_pipefs... > > I haven't looked at it. I've just assumed that since Trond and Kevin > have both looked at both API's, then there must be some good reason > we're not using it.... Kevin has spent quite some time working on the keyring support, but as far as I understand the amount of time he can continue to spend working for CITI has recently been heavily reduced... -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- 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
