[linux-cifs-client] Add support infrastructure for Named Pipe

Jeff Layton jlayton at redhat.com
Fri Oct 16 07:19:36 MDT 2009


On Fri, 16 Oct 2009 07:35:33 -0500
Steve French <smfrench at gmail.com> wrote:

> On Fri, Oct 16, 2009 at 7:06 AM, Jeff Layton <jlayton at redhat.com> wrote:
> > On Thu, 15 Oct 2009 18:55:57 -0500
> > Steve French <smfrench at gmail.com> 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 <jlayton at redhat.com>


More information about the linux-cifs-client mailing list