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