Re: Add support infrastructure for Named Pipe

On Fri, 16 Oct 2009 07:35:33 -0500
Steve French <[email protected]> wrote:

> On Fri, Oct 16, 2009 at 7:06 AM, Jeff Layton <[email protected]> wrote:
> > On Thu, 15 Oct 2009 18:55:57 -0500
> > Steve French <[email protected]> wrote:
> 
> > Shoving code into the kernel to work around licensing problems is not a
> > good solution. All of those problems can equally be solved by a daemon
> > that runs in userspace.
> 
> Not sure I would describe adding two or three SMB calls "shoving code into
> the kernel" especially as this in kernel in most other OS and fits with
> the kernel layer.   Remember that no one is suggesting adding DCOM
> and RPC to kernel - just the ability to do a couple missing primitives
> (e.g. transact and setnmpstate) which makes the user space code eaiser.
> 
> > I'm not of the opinion that an extra connection to the server is a huge
> > deal. At least, not a big enough problem to warrant doing this in
> > kernel rather than in userspace.
> 
> It seems insane to creating a dependency on a userspace daemon
> which has to hang around just to avoid adding a couple of wire requests
> (especially since these transact calls aren't really written in userspace
> this way).  Even with  userspace IPC to a GPL daemon I have heard concerns
> that that is frowned upon (IANAL).
> 

I don't think it's insane at all. It seems perfectly reasonable to have
a standalone CIFS named pipe service daemon rather than doing this in
kernel.

IANAL either, but I don't see how this would be any different
than talking to any other general-purpose service (syslog or the
resolver, for instance). To my understanding, whether this code is in
kernel or userspace is somewhat irrelevant as long as you're not
linking to it.

Either way...I think we should focus on the best technical solution for
this and worry about licensing once we settle on that.

> > With what you have so far, WINE will need to mount the IPC$
> > share in order to use it.
> 
> I am not suggesting that we give WINE elevated priv.
> 

But you are. Something has to mount this IPC$ share, right? CIFS only
open sockets to servers when someone does an actual mount. This
patchset doesn't change that.

Again, it's very difficult to discuss this without understanding how
you intend for userspace to actually use this support. Can you outline
how you envision userspace programs using this new code?

-- 
Jeff Layton <[email protected]>