Re: Add support infrastructure for Named Pipe

> the only user of this support that has ever been identified is WINE.
I have had requests over the years for adding the few missing calls,
from a lot more than from WINE.  Various distros have to ship multiple
versions of Samba with conflicting licenses to work around problems in
desktops, and the libsmbclient is not appropriate for everyone.  For a
while it looked like Centeris/Likewise would address some of the need
(presumably not an option for most distros though) but even with that
it is messy to have userspace making connections when kernel code
already has a connection to the same server.

> I don't think this stuff has any place in the kernel.  Just implement the named pipes directly in wine.
I agree that all code that is above the SMB/CIFS layer could (and
should) be put in user space (probably in a new helper library, since
Samba currently doesn't have anything which matches exactly, and I
have seen requests from others over the last few years for something
like what Centeris was trying to do with librpc for dcom over pipes),
but it doesn't make much sense to reimplement another cifs client in
user space, when pipe operations use (mostly) read and write SMBs.
As far as I can tell, there are only a couple of additional SMBs that
this patch suggests adding and it looks straightforward, and much much
easier than adding a whole new SMB/CIFS client in user space.   CIFS
already had support for mounting to IPC$ shares and opening a pipe
(pipes are similar to file objects), but it turns out that for a
userspace library to take advantage of that it is helpful to add
transact and two other ioctls.   Seems much easier to do it this way,
and will avoid having to renegotiate multiple tcp sockets from the
same client (which conserves server resources).

> You'll need infrastructure too to actually handle doing some
> sort of implicit "mount" of an IPC$ share when ...
> new 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?

We have to do that (automatic session setup if we don't have an smb uid
for this uid) anyway in cifs.ko (just as NFS has to autoconnect).
Today (in cifs), we use the credentials that match the pid (if we know
them, and use the default if we don't).   This needs to be fixed
to allow obtaining credentials from userspace (whether or not
pipe support is added) so is a different issue.

Since this patch is fairly small, and the smbs fit with what cifs already does,
I think it makes sense.   The userspace DCE/RPC code (which Shirish has
prototyped and tried various versions of) is the majority of the code, but
doesn't have to go in kernel - would go in a new Samba lib presumably.



-- 
Thanks,

Steve