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

[Jeff Layton]

On Mon, 19 Oct 2009 09:42:52 -0500
Shirish Pargaonkar <shirishpargaonkar at gmail.com> wrote:

> On Mon, Oct 19, 2009 at 9:04 AM, Jeff Layton <jlayton at redhat.com> wrote:
> > 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>
> >
> 
> Jeff,
> 
> Couple ot fhings.
> 
> 1. There would/could be other apps besides WINE which interface with named pipes

Sure, ok. WINE is the obvious user of the named pipe code, but I
suppose there can be others. Still, you have the same problem of how to
handle this "mounting".

> 2. Will work on getting the ioctls code coded better

I don't have a problem with the ioctl coding itself (honestly, I
haven't reviewed that part of it). My issue is rather with the entire
approach of trying to shoehorn this stuff into the kernel's VFS API.
It's a kludgey solution that hamstrings you later if you decide that it
needs changes.

> 3. Not sure yet, but this is what could happen (still nebulous about
> the implementation)
>    We have a /cifsipc directory created when cifs is loaded
>     When a user using an app (such as WINE) opens a pipe, lookup
> triggers cifs upcall
>       to get credentials for session setup and tree connect.
>     So can then have pseudofiles like /cifsipc/servername/user_id as a
> result of nt create andx
>
> Basically what a user space library does for utlities like smbclient,
> can same not be done in
> the kernel? Do not think there will be too much new code here.

You can pretty much do anything you want in the kernel, in principle.
The question is whether you should. Given that this code is going to be
essentially useless without a userspace library, putting this in the
kernel seems to have more disadvantages than advantages.

-- 
Jeff Layton <jlayton at redhat.com>