Re: [RFC PATCH 0/5] SUNRPC: "RPC pipefs per network namespace" preparations

[Stanislav Kinsbursky]

20.10.2011 16:32, bfields@xxxxxxxxxxxx ÐÐÑÐÑ:
> On Thu, Oct 20, 2011 at 03:06:46PM +0400, Stanislav Kinsbursky wrote:
> > Guys, please, spend some of your expensive time to review this patch-set briefly.
>
> I'll try to take a look soon, but I'm travelling tomorrow through the
> 31st, and things will be a little hectic.

Thanks for your time, Bruce.

> Just one quick comment:
>
> > > The only problem about I'm not sure how to solve properly yet, is auth gss
> > > pipes creations operations. Hoping for some help with it.
>
> I suspect one reason it may be a little complicated is the
> upcall-version switching.  The old version is deprecated, and there's no
> need to support the combination of the old version with the a new
> feature like containers.  And now that it's been there a while the
> version-switching code already achieved its goal of avoiding a flag day.
> So, one approach might be:
>
> 	- move all the code for the old gss upcall and for the version
> 	  switching under a new CONFIG_DEPRECATED_GSS, or similar.
> 	- print a warning if the old stuff is used, and plan to rip it
> 	  out completely in a future kernel version.
> 	- do something that works just in the !CONFIG_DEPRECATED_GSS
> 	  case.

Thanks for this comment. I'll check the code for problem you mentioned here.
But I was actually talking about other thing.
Currently we create pipe in gss without any checks since we assume, that pipefs 
client dir is created already.
But with approach, represented in this patch set, pipes and dirs will be created 
only when pipefs was mounted from user-space. I.e. clients with gss auth may 
already present and some callback is required for creating gss pipes.
And also this approch assumes existence of gss auth without pipe.

> Would that help?
>
> --b.


--
Best regards,
Stanislav Kinsbursky
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/