Samba4 libsmb* design draft
Stefan Metzmacher
metze at metzemix.de
Tue Nov 25 14:26:15 GMT 2003
Tom Jansen wrote:
>Hello everyone,
>
>I've been browsing through the samba4 libcli/* code the last few days
>and I must say that I'm impressed by it's cleanness.
>
First I would like to have one libsmb.so (libsmb.a)
And it should include the SMB protocol AND the DCERPC protocol
but this lib should offer different interfaces (with providing different
headers)
>- libsmbcli:
>The lower level API. Uses the lowest level cli_raw* functions to talk to
>SMB servers. The API should be completely async. This is quite a large
>job but adding asyncness will be very usefull. If everything is async,
>the need for reentrant code at this level is low, locking can be done on
>large structures (for example cli_state structures) because we will not
>be waiting for IO operations to complete. This will be a minor
>performance impact, but it greatly simplifies locking and thus reduces
>the probability of deadlock-bugs and its friends.
>As I already mentioned, everything that does IO should be async. It
>should be useable by client apps like smbclient so bugs have to be fixed
>at one single point.
>
>
(#include <libsmb/smb.h>
#include <libsmb/dcerpc.h>)
Should this be the same API as in the samba internals? so all cli_*
functions from libcli/raw/*
and librpc/rpc/*
With this a client could be fully controll what he want to send to the
server...
>- libsmbclient_async
>This lib will have a posix-like API that can use the power of asyncness.
>It will not be reentrant because that's not necessary. You can call it
>posix with callback if you like. Commands will be given in structure's
>that can look like:
>
>struct SMBC_ASYNC_COMMAND {
> /* Id to track this command */
> unsigned int id;
>
> enum {SMBCLIENT_OPEN, SMBCLIENT_READ, SMBCLIENT_WRITE,
>SMBCLIENT_CLOSE, SMBCLIENT_READDIR....} type;
>
> union command_parms {
> struct open {
> const char *pathname;
> int flags;
> mode_t mode;
> SMBC_FILE *retval;
> };
> struct read {
> SMBC_FILE *fd;
> void *buf;
> size_t count;
> ssize_t retval;
> };
> etc..
> };
>
> /* Error that occured in various formats */
> struct error error;
>
> struct async {
> void (*fn)(struct SMBC_ASYNC_COMMAND *);
> void *private;
> }
>}
>
>an example function definition for an open call would look like:
>
>int smbc_ctx_async_open(SMBC_ASYNC_CTX * ctx, SMBC_ASYNC_COMMAND * cmd);
>
>If everything is succesful the unique id is returned.
>
A unique id for command? how can I check for an error?
What if we run out of id's? Note one app should be able to run over years
>completed the callback
>It will be reentrant by using a async mechanism from libsmbcli with
>locking.
>Connection caching and management will be transparant to the user by
>default, but it'll be controllable. For example, a callback for a broken
>connection can be called and depending on it's retval the connection can
>be automagically reestablished or terminated.
>
>
(#include <libsmb/smbc.h>)
This should be a full async interface but with posix errors and
funtions, right? (I'm not shure if I got what you exactly mean...)
Also sync support should be also available if the call_back fn pointer
is NULL
unsigned int smbc_command(SMBC_COMMAND *cmd);
struct SMBC_COMMAND {
/* Id to track this command */
unsigned int id;
/* pointer to our SMBC_CTX */
SMBC_CTX *ctx;
enum {SMBCLIENT_OPEN, SMBCLIENT_READ, SMBCLIENT_WRITE,
SMBCLIENT_CLOSE, SMBCLIENT_READDIR....} type;
union command_parms {
struct {
struct {
const char *pathname;
int flags;
mode_t mode;
}in;
struct {
SMBC_FILE *retval;
}out;
}open;
struct {
struct {
SMBC_FILE *fd;
void *buf;
size_t count;
}in;
struct {
ssize_t retval;
}out;
}read;
etc..
};
/* Error that occured in various formats */
struct error error;
struct async {
void (*fn)(struct SMBC_COMMAND *);
void *private;
}
}
>- libsmbclient_posix:
>The highest level API that behaves just like the samba3 libsmbclient but
>without the "unexpected features" :)
>It will be reentrant by using a async mechanism from libsmbcli with
>locking.
>Connection caching and management will be transparant to the user by
>default, but it'll be controllable. For example, custom caching
>functionality like samba3-libsmbclient can be available.
>
>
Maybe this should be supported but should be marked depricated, new apps
should use the <libsmb/smbc.h> API!
#include <libsmbclient.h> or <libsmb/smbc_compat.h>
--
metze
-------------------------------------------
Stefan (metze) Metzmacher <metze at metzemix.de>
More information about the samba-technical
mailing list