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

[Jeff Layton]

On Sun, 18 Oct 2009 20:22:41 -0500
Steve French <smfrench at gmail.com> wrote:

> On Sun, Oct 18, 2009 at 7:12 PM, Christoph Hellwig <hch at infradead.org> wrote:
> > On Fri, Oct 16, 2009 at 09:05:18AM -0400, Jeff Layton wrote:
> >> Well...all of this code seems to presuppose that there will be actual
> >> filesystem objects on which to operate. IOW, you can't call an ioctl on
> >> a non-existent filehandle.
> >>
> >> Again, it's not at all clear from this patchset how userspace will
> >> actually use this code. How do you envision userspace programs actually
> >> making use of this?
> >
> > Yeah.  I have no problem adding kernel support for the named pipes to
> > the kernel if we really need to, but:
> >
> >  - please odn't shove it into a filesystem as that's a totally unrelated
> >   abstraction
> >  - write some proper code for it, not the thing that was submitted
> >   adding random ioctls dereferecing user pointers and similar.
> >   Incidentally moving it out of cifs will make that a lot easier as
> >   bad code doesn't really stick out in cifs.
> 
> Problem with making them via something other than an ioctl is -
> they are handle based ops and operations on pipes
> are the same on the wire as open/close/read/write
> operations on files so the majority of this already works (these
> are the client not server side of pipe operations Shirish
> is talking about).   The missing operations
> are handle based (e.g. transact and get/set named pipe info)
> so ioctls seem reasonable and  I don't know of an obvious
> alternative to ioctl, to do handle based operations.   Certainly it is much
> smaller to do a few ioctls  than the alternatives and the ioctls can easily
> be hidden by a user space library as apparently
> Shirish did in a prototype and saves having to write a new cifs client
> from scratch.
> 

You don't need to write a new cifs client from scratch, there are
libraries that can take most of that work off of your hands
(libsmbclient, as an example though there are others).

You've just articulated the main reason that I feel that a
filesystem-based interface to this code is a poor fit. Rather than
doing this:

WINE -> VFS interface -> Wire Protocol

...it makes much more sense to do this:

WINE -> Pipe Daemon -> Wire Protocol

The inteface between WINE and the pipe daemon can look however you
wish, and you're not going to have to implement ioctls here.

Even if you do this, and hide all of the ioctl ugliness behind a
userspace library it's still not at all clear to me how you intend to
use this code. The question I still have is this:

"In the likely event that WINE wants to talk to a host to which you have
no preexisting CIFS mount, what's going to set up the mount to the IPC$
share?"

-- 
Jeff Layton <jlayton at redhat.com>