libsmb2, meet samba
metze at samba.org
Wed Apr 26 06:53:00 UTC 2017
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?
> Not bloated yet, almost fitting in memory of a Sinclair Spectrum:
> $ ls -l lib/.libs/libsmb2.so.1.0.0
> -rwxrwxr-x. 1 sahlberg sahlberg 51816 Apr 25 16:05 lib/.libs/libsmb2.so.1.0.0
> 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
Global variables should also be [static] const.
> 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.
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: OpenPGP digital signature
More information about the samba-technical