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

[Shirish Pargaonkar]

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
2. Will work on getting the ioctls code coded better
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.