[linux-cifs-client] [patch][0/3] Add support infrastructure for Named Pipe

Jeff Layton jlayton at redhat.com
Thu Oct 15 13:58:13 MDT 2009


On Thu, 15 Oct 2009 12:36:23 -0500
Shirish Pargaonkar <shirishpargaonkar at gmail.com> wrote:

> Add Named Pipe support in cifs client.
> 
> Since there are no equivalent kernel APIs for transactions, most of the
> SMBTrans
> functions are implemented using ioctls which are handle based, like the
> APIs used for Named Pipes.
> 
> A path based function, WaitNamedPipe is not implemented at this time.
> Also not implemented support for multiple fragments in TransactNmPipe
> function.
> 


The downsides of doing this in kernel seem to outweigh the advantages.
Here's my reasoning...

This is something that is far, far better done in userspace. Lets be
clear here -- the only user of this support that has ever been
identified is WINE. Why would it not be better to have this either
implemented directly by WINE or handled by another userspace service?

The only reason I've heard so far that anyone wants to do this in
the kernel is for licensing reasons. WINE is LGPLv2 and libsmbclient
is GPLv3, so WINE can't really use libsmbclient. This strikes me as a
very bad reason to put this infrastructure in the kernel. A standalone
userspace daemon that implements this seems like a better way to deal
with the licensing problems.

If you do this in a userspace daemon, then you're also not constrained
by a VFS interface, and won't need to do ugly stuff like implement
ioctls for calls that don't exist in Linux. Have WINE talk to the
daemon using a standard IPC mechanism (maybe a FIFO or unix socket?),
and have the daemon turn those into on the wire SMB calls.

It's also not clear to me how you're going to hook WINE up to this
plumbing. You'll need infrastructure too to actually handle doing some
sort of implicit "mount" of an IPC$ share when WINE wants to talk to a
new host (there is no guarantee that you'll have an existing CIFS mount
to this host).

What's going to trigger the "mount" the IPC$ share? What if I have
multiple users on the same host that want to talk to the same server?
How will credentials be handled?

Again, this is something much easier to handle with an all-userspace
solution. A userspace daemon can talk to winbind et. al. and deal with
creds that way.

-- 
Jeff Layton <jlayton at redhat.com>


More information about the linux-cifs-client mailing list