Fwd: Generalising SMB1 libsmb code
Luk Claes
luk at debian.org
Sat May 26 10:30:48 MDT 2012
On 05/25/2012 03:48 PM, Stefan (metze) Metzmacher wrote:
> Hi Luk,
Hi metze
>> For generalising the code (getting rid of cli_state) in
>> source3/libsmb, I keep stumbling on the same function, where I
>> could need some advice:
>>
>> cli_smb_req_create calls smb1cli_req_create, so it would be
>> logical to try to replace cli_smb_req_create with
>> smb1cli_req_create, though the latter has additional arguments:
>>
>> clear_flags: depends on cli->case_sensitive additional_flags2:
>> depends on cli->dfsroot pid: 0xFEFF as before? How does it get
>> the actual pid from that btw? uid: cli->smb1.uid
>
> The pid is important for smb1, I'm not sure yet where to store it
> in future...
You mean in the conn structure or session structure? Does the pid
change for different sessions on the same connection?
>> So how do I get the cli->case_sensitive, cli->dfsroot and
>> cli->smb1.uid (or the flags and uid) when I don't have cli, but
>> have smbXcli_conn and smbXcli_session?
>
> The first might be that we use smbXcli_session also for smb1.
>
> And replace cli->smb1.uid with cli->smb1.session.
Ok, have done that.
> I think for now hide the change in cli_state_get_uid() and
> cli_state_set_uid().
I've started this way, but introduced smb1cli_session_{g,s}et_uid and
used these in the end to get rid of the cli_state ones.
> Then we need a smbXcli_tcon, first it should only be a simple
> wrapper to int value, later we can add more stuff, like per share
> flags, which could indicate if it's a dfsroot and the share
> supports FILE_CASE_SENSITIVE_SEARCH.
I have done that too and replaced the use of tcon_id parameters for
smb2 functions to use the new tcon structure instead.
>> In the meantime I have worked a bit from the other side (getting
>> rid of cli_state and some other functions), pushed to
>> git://anonscm.debian.org/users/luk/samba.git like before.
>
> Most of them look good, but I'm not sure if the 'split' patches
> are the correct way to do it, maybe put them at the end of the
> patch stream.
Ok, I have put them to the end of that patch stream. Any more feedback
welcome so it will be the correct way :-)
> If you still need something to work on maybe have a look at
> https://lists.samba.org/archive/samba-technical/2012-February/081871.html
>
>
and start with a smb_transport abstraction for bsd sockets.
> Basically a wrapper arround read_smb_send/_recv and
> writev_send/_recv
Will start looking into this unless you think it makes more sense to
start adding the flags to the tcon structure and find a solution for
the pid first.
Cheers
Luk
More information about the samba-technical
mailing list