Re: [RFC PATCH 1/5] sunrpc: don't wait for write before allowing reads from use-gss-proxy file

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 1515 bytes --]

On Thu, 2 Jan 2014 16:21:50 -0500 "J. Bruce Fields" <bfields@fieldses.org>
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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]