libsmb2, meet samba

[ronnie sahlberg]

On Fri, Jan 27, 2017 at 10:11 AM, Steve French <smfrench at gmail.com> wrote:
> I would also strongly recommend hosting it on samba.org, and there is
> some value if (at least) some of the headers can be shared.  Although
> cifs code had been ported to user space for testing (for spec e.g.), I
> like this better.
>

Thanks Steve. I appreciate your input.

> My only nit (and it is a small one), is noting that at this stage
> there is near zero value (and some disadvantage in additional testing
> and coding) in enabling SMB2 dialect, it is easy enough to focus 100%
> on SMB3 and later dialects (or SMB2.1 or later). Leaving off the
> optional features of SMB3 until they are ready is fine, but there is
> almost zero value in ever negotiating SMB2 at this stage - but there
> would be HUGE value in having a good user space SMB3.0 or SMB3.11
> library that could be more broadly used by open source components that
> won't link to Samba today.

ACK, Switching to SMB3+ only support is a good idea. I absolutely also
want to get RDMA offload into this library just like libnfs.


I will do that. I do not have any real time to work on this this
weekend but will next weekend.
For now, see this as a q-n-d proof of concept.
I will need to spend time to clean things up a bit first.
For example, not having offsets hardcoded. Not even have offsets
exposed in the structures exposed in the API
but have them utomatically computed in the marshalling/unmarshalling functions/
There is a whole lot of cleaning up to do.
I need to audit all error paths, check for memory leaks, and buffer
overruns. etc.


I agree that there is immense value in a small, and liberally
licenced, smb3+ client.



After that I will want to have a look at your kernel code.
I think it would be very useful if we can share code. In particular
sharing the code to marshall/unmarshall smb2 pdus and infolevels are
obvious points where we can work together.
Also codepaths where we do things such as the mapping from things like
O_RDWR/O_...    to the arguments to the NTFS API are other areas.

I am very open to do this but you have to bear with me until I get
time to pick this up again in a week or two.


regards
ronnie sahlberg