[PATCH] Have the smbcli_session record the OS and Native LANMAN of the remote server

[Sam Liddicott]

[followups trimmed]
* Stefan (metze) Metzmacher wrote, On 02/05/09 08:14:
> Sam Liddicott schrieb:
>   
>> That looks neatly done.
>>
>> Thanks
>>
>> I want to add a getShareInfo to ntvfs's ops so that srvscv dcerpc server will ask the vfs to do the getShareInfo; do you have any feelings on this?
>>
>> It allows vfs to more easily customize the response as well as aiding more transparent proxying.
>>
>> Currently I have proxy specific code in the srvsvc service which is pretty rotten, but serves as a god proof of concept trst.
>>     
>
> Sounds ok.
>
> BTW: What's with the idea of passing smb_tcon to ntvfs_connect(), do you
> have a patch for that yet?
>   
(I've been away) but I'm now looking at having ntvfs_connect accept
union smb_tcon

That union has 3 members, I started looking at the usual method by
creating: ntvfs_map_connect() to convert to a standard form generic but
this seems bad for 2 reasons

1. there's a lot of non-overlap between the various out structs.
I could just make the generic version be a full superset, and
*_connect() implementations will just have to fill them all, but it
doesn't seem satisfactory for a vfs module to fill in max_xmit when the
calling function knows that the client won't even receive this information.

2. There's a lot of ntvfs_next_connect() being used in different ntvfs
modules, which means the next called vfs module may or may not get a
mapped tcon level, depending on whether or not the previous vfs module
called ntvfs_map_connect(). This makes me un-easy as it hints of
different runtime behaviours for vfs that don't want to call
ntvfs_map_context() but where another vfs module has done this for them.

Another solution is to have each ntvfs NOT convert the non-normalized
union into a generic level, and instead have each vfs module manage the
variations themselves, perhaps with helper macros to get at some of the
in values like path/sharename etc.

But we have the added joke that smbsrv_tcon_backend is also a consumer
of the union smb_tcon and has to have tcon level specific code in, and
this function cannot easily benefit from a helper such as
ntvfs_map_connect (which now doesn't seem so helpful).

This all makes me lean towards this strategy:
1. expose all levels to ntvfs_connect
2. let functions call ntvfs_map_connect if they want, but only if they
didn't call call ntvfs_map_connect
3. have helper macros for getting common data values out of the structs
independant of level

then I just need to deal with current behaviour of implying the
tcon->xxx.out values through
req->tcon->ntvfs->(dev_type|fs_type|options) etc

I guess that should stop if the smb_tcon is being passed directly to the
vfs modules.

As for coding style, I'm following the coding style in the surrounding
functions for the files I edit. It may or may not be out of favour, but
it fits in. It means sometimes doing:
  NT_STATUS_HAVE_NO_MEMORY(con->generic.out.dev_type)
and sometimes:
  if (con2 == NULL) {
          return NT_STATUS_NO_MEMORY;
  }

Have you a preference out of these two?

Sam