libsmb2, meet samba

ronnie sahlberg ronniesahlberg at
Fri Apr 28 02:08:47 UTC 2017

Stephan, Thanks for your review.

On Tue, Apr 25, 2017 at 11:53 PM, Stefan Metzmacher <metze at> wrote:
> Hi Ronnie,
> Am 26.04.2017 um 01:26 schrieb ronnie sahlberg via samba-technical:
>> Update. Start of unstructured brain dump:
>> Libsmb2 is nearing its first official release. Which means it has all
>> the features that QEMU and KODI (main consumers) need.
>> Please have a look at my github repo.
>> Libsmb2 is fully async and non-blocking.
>> It does zero-copy for both READ and WRITE commands, in the sense that
>> it reads/writes the application buffer directly to/from the socket
>> without any memcpy() being done in the library itself.  True zero-copy
>> will have to wait until RDMA support comes.
>> It also supports compounded requests making the common pattern of
>> CREATE/do-something/CLOSE execute in a single roundtrip.
>> This should make a lot of metadata operations fast-ish.
> Can you point me to the code that takes care of the credit handling?
> Do you support large reads and writes using SMB2_CAP_LARGE_MTU?
> Or is this basically just the SMB 2.02 feature set?

Yes, and yes. I just added this in :

I still need to enforce the 64k for !multi_credit in the
smb2_[p]{read|write} functions.

>> Not bloated yet, almost fitting in memory of a Sinclair Spectrum:
>> $ ls -l lib/.libs/
>> -rwxrwxr-x. 1 sahlberg sahlberg 51816 Apr 25 16:05 lib/.libs/
>> No external dependencies outside from MIT and basic libc making it,
>> very portable.
>> As I am not fluent in Visual Studio I would welcome any help I can get
>> to set up a proper VS project file.
>> At this point I think the library is in a usable state and the API
>> should be declared stable.
> I'd propose to use 'uint8_t' instead of 'char' for buffers.
> And also add as much 'const' to pointers within structs and
> function arguments.
> Global variables should also be [static] const.

Good hygiene suggestions. Done.

>> Some features should still be added but as far as main consumers, i.e.
>> QEMU and KODI, are concerned we
>> are in a releasable state for 0.1 feature wise.
> While I don't really like the callback based api, I guess it's that
> way because libnfs uses something like this, which makes it easier
> to adopt for the main consumers.
>> I was chatting with Jeremy about features that would be nice to add
>> after the 0.1 release and I would be happy to work with anyone
>> that wants to contribute.
>> My idea of such post 0.1 features would be :
>> * krb5 support. Currently only gss-ntlmssp is supported but adding
>> krb5 support should be trivial.
>> * sing and seal.
> You should also ask gss_init_sec_context for GSS_C_INTEG_FLAG,
> even without signing in use.
>> * visual studio 1* project files and support.
>> * SET_INFO support
>> * a simple cifs fuse module.
>> * RDMA (this is probably not a near term goal)
> As the api is very low level and (as far as I can see)
> only based on SMB 2.02 features, I guess it will be hard
> to add features like encryption, multi-channel and smb-direct.

Like libnfs, there are both highlevel posix-like APIs (sync and async)
as well as a raw low level smb API.
For now it is mostly <=2.02 level, except for the large_mtu support.

> But it's very good to have a start that seems to work,
> it can always be improved later.
> Do you have some QEMU code that uses this api?

It will basically be almost identical to;a=blob;f=block/nfs.c;h=6541dec1fcc1afd46a6226ae7c0381b6b9f727f5;hb=81b2d5ceb0cfb4cdc2163492e3169ed714b0cda9
Once I cut the first initial pre-release Peter (the guy that now
maintains qemu nfs and iscsi) will create smb2.c for qemu.

Later on it would be very nice to add both SMB Direct as well as
discard/unmap support as both features are very important for
cloud/enterprise/qemu users.

More information about the samba-technical mailing list