libsmb2, meet samba

[Stefan Metzmacher]

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?

> 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
function arguments.

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?

Thanks!
metze



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170426/24722871/signature.sig>