On Mon, 6 Jan 2014 09:37:44 +1100 NeilBrown <neilb@xxxxxxx> wrote: > On Thu, 2 Jan 2014 16:21:50 -0500 "J. Bruce Fields" <bfields@xxxxxxxxxxxx> > wrote: > > > On Wed, Jan 01, 2014 at 07:28:30AM -0500, Jeff Layton wrote: > > > It doesn't make much sense to make reads from this procfile hang. As > > > far as I can tell, only gssproxy itself will open this file and it > > > never reads from it. Change it to just give the present setting of > > > sn->use_gss_proxy without waiting for anything. > > > > I think my *only* reason for doing this was to give a simple way to wait > > for gss-proxy to start (just wait for a read to return). > > > > As long as gss-proxy has some way to say "I'm up and running", and as > > long as that comes after writing to use-gss-proxy, we're fine. > > > > > Only tangentially related to the above email ..... > > I had a look at this new-fangled gssproxy thing and while it mostly seems > like a good idea, I find the hard-coding of "/var/run/gssproxy.sock" in the > kernel source .... disturbing. > You never know when some user-space might want to change that - maybe to > "/run/gssproxy.sock" (unlikely I know - but possible). > > Probably the easiest would be to hand the path to the kernel. > > e.g. instead of writing '1' to "use-gss-proxy", we could > echo /my/path/gss-proxy-sock > /proc/net/rpc/use-gss-proxy > > Then you could even use an 'abstract' socket name if you wanted. i.e. one > starting with a nul and which doesn't exist anywhere in the filesystem. > I would feel a lot more comfortable with that than with the current > hard-coding. > I like that idea -- particularly if you keep the legacy behavior that writing a '1' to the file makes it default to /var/run/gssproxy.sock so we don't break compatability with older gssproxy releases. -- Jeff Layton <jlayton@xxxxxxxxxx>
Attachment:
signature.asc
Description: PGP signature
