Re: Add support infrastructure for Named Pipe

On Mon, Oct 19, 2009 at 9:56 AM, Volker Lendecke
<[email protected]> wrote:
> On Mon, Oct 19, 2009 at 09:42:52AM -0500, Shirish Pargaonkar wrote:
>> 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.
>
> Let me ask another question: Why do you insist on putting
> this into the kernel? What's the deeper problem that you can
> not solve in user space?

a few quick points:
1) Easier: Even without extending cifs.ko with anny new ioctls, we
already can do simple RPC operations over existing cifs.ko today (with
prototype user space code that does the DCE part bind etc.).
Currently there is no user space SMB client library that could be used
broadly by Linux applications and tools, although libsmbclient can be
used by those which are gpl.  This has been a huge headache over the
years (and causes distros to ship conflicting levels of samba
libraries, and still not address the problem).  After long discussions
with jra, gd, and others, I don't see any way that we can convert
libsmbclient and libnet to lgpl.  At least two developers told me they
didn't like doing userspace IPC to a new gpl libsmbclient daemon to
avoid GPL (even if it could be made stable).   Easiest to simply use
the existing kernel cifs code to use cifs file/pipe support - and just
work on the user space rpc pieces by adding a new lgpl library for rpc
to Samba client (user space).  Shirish prototyped this for - it uses
existing cifs.ko, but user space code for RPC.  For example - if you
want to list what servers or shares are available (e.g. in
mount.cifs), why use different code to list the shares and connect to
the shares?  Those pipe examples already basically work with current
cifs code (without the ioctls) but Luke's comments mentioned that the
PeekNamedPIpe and GetHandleNmPipe SMBs (which were part of Shirish's
small ioctl patch) would be useful for others so thus the motivation
for Shirish's patch (after he read the Wiki on the topic).

2) Affinity with other file objects: Although not available in Linux -
named pipes are treated as file objects on every other OS since they
were invented (in OS/2), and so the client side is implemented in
kernel in all the cases I can think of (Windows, OS/2 etc.).  Other
pseudofiles (such as fifos, char devices etc. created in Linux via
mknod) are treated as file objects today in kernel.  The client side
named pipe code is of course small, since it is just file operations
over SMB/CIFS (or SMB2).   The server side is already implemented in
Samba server.

3) Usability: Since the file system client does not use the server's
(or smbclient's) smb.conf file for configuration settings (security
levels, signing etc.), it can be confusing e.g. to list shares with
smbclient (with looser security settings) and not be able to connect
to the share (with cifs.ko using stricter security settings).

4) Performance: The cifs kernel client can connect to a server and
keep a session - but with smbclient and the libsmbclient model in
general you can end up reconnecting dozens of times to the server from
the same client (even though a session to the server already exists in
kernel).  In addition connecting via to the same server from via
smbclient from (when you already e.g. have a kernel mount to it) can
cause the "SMB NAT problem" in some versions of Windows.

-- 
Thanks,

Steve