On Thu, 15 Oct 2009 12:36:23 -0500 Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx> wrote: > Add Named Pipe support in cifs client. > > Since there are no equivalent kernel APIs for transactions, most of the > SMBTrans > functions are implemented using ioctls which are handle based, like the > APIs used for Named Pipes. > > A path based function, WaitNamedPipe is not implemented at this time. > Also not implemented support for multiple fragments in TransactNmPipe > function. > The downsides of doing this in kernel seem to outweigh the advantages. Here's my reasoning... This is something that is far, far better done in userspace. Lets be clear here -- the only user of this support that has ever been identified is WINE. Why would it not be better to have this either implemented directly by WINE or handled by another userspace service? The only reason I've heard so far that anyone wants to do this in the kernel is for licensing reasons. WINE is LGPLv2 and libsmbclient is GPLv3, so WINE can't really use libsmbclient. This strikes me as a very bad reason to put this infrastructure in the kernel. A standalone userspace daemon that implements this seems like a better way to deal with the licensing problems. If you do this in a userspace daemon, then you're also not constrained by a VFS interface, and won't need to do ugly stuff like implement ioctls for calls that don't exist in Linux. Have WINE talk to the daemon using a standard IPC mechanism (maybe a FIFO or unix socket?), and have the daemon turn those into on the wire SMB calls. It's also not clear to me how you're going to hook WINE up to this plumbing. You'll need infrastructure too to actually handle doing some sort of implicit "mount" of an IPC$ share when WINE wants to talk to a new host (there is no guarantee that you'll have an existing CIFS mount to this 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? How will credentials be handled? Again, this is something much easier to handle with an all-userspace solution. A userspace daemon can talk to winbind et. al. and deal with creds that way. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
