svn commit: samba r10721 - in branches/SAMBA_4_0/source/pidl/lib/Parse/Pidl/Samba3: .

Jelmer Vernooij jelmer at
Wed Oct 5 11:19:21 GMT 2005

Hash: SHA1

Hi Tridge,

tridge at wrote:

> Jelmer,
>> Example output is still available at
> Wouldn't it be easier to keep the same generated code as Samba4,
> and just replace the C ndr encoding glue? Is there some reason we
> need to use a different form for the generated code?

Using the current API is by far the easiest solution. Writing these 5
backends to pidl took me two evenings, writing glue or even replacing
the rpc_* directories in Samba3 now would've taken me a lot more time.
One of the other reasons for this approach is the fact that we can
replace one pipe at a time
instead of all of them. I remember Volkers' branch that tried to
backport librpc/, which died for that reason AFAIK.

> Ideally I'd like to see all of librpc/ ported back, but if we can't
> do that for some reason then going half way and keeping the
> generated code would at least allow future work on pidl to be
> shared between Samba3 and Samba4.

The two things don't necessarily exclude each other. In order to
migrate to the Samba4 librpc/, I see these steps:

- - Make all interfaces in Samba3 autogenerated (without changing the
API). This can be done one pipe at a time
- - Bring in librpc/ndr/ and change autogenerated client/server code to
call a different (Samba4) parser
- - Bring in librpc/rpc/ and change all calls to the RPC client code in
Samba3 to use the Samba4-style API (with structs)
- - Bring in Samba4's server code.

These can all be done one at a time, making that port easier. Not all
of them have to be done, and I'm not sure if doing all of them is a
good idea, but I'll leave that decision up to the Samba3 developers
(I'll just stick to the Samba3 pidl backend).

Both backends already do pretty much everything that's in the NDR
spec, and that's all we need for these pipes.

> The problem I see with creating a new backend is that most of the
> really tricky work is in the backend specific code, especially for
> things like subcontexts and multi-level pointers. By comparison the
> ndr glue code is incredibly simple, consisting of tiny C functions
> that do things like "push a uint32". Writing those for Samba3 is
> completely trivial, whereas getting all the details right on a new
> backend is much harder, and then maintaining the two is even more
> work.

You make it sound harder then it is :-) Most of the hard code is in
the NDR module, which is shared between the Samba3, Samba4 and
Ethereal backends. The Samba3 backend already does most of NDR now
(and it only has to do so for one kind of function rather then three
(pull,push,print)). Things like subcontexts and multi-lever pointers
aren't implemented yet, but are trivial to do now.


Version: GnuPG v1.4.2 (GNU/Linux)


More information about the samba-technical mailing list