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. NeilBrown
Attachment:
signature.asc
Description: PGP signature
