The Wrapper Project

[Michael Adam]

Hi Andreas,

I am very sorry to join so late, but somehow these discussions
had slipped my attention during summer. Today we hit this topic
in a chat, so I read back through the mail thread and would like
to make a few comments:

This is really great interesting and useful work you are doing!

I really like the idea of making these wrapper libraries
generally useful and publish them separately for other projects
to use for testing in other projects.

What I don't like at all is the approach to first rip them out
of the samba tree, work on them completely off-record and then
change samba to use these augmented external copies once they
are ready.

I would have argued that our usual mode for development of
features should have been applied: prepare stuff in a personal
samba git repo/branch, present the patches for review, bring
the changes into samba (so samba uses the new features internally
as early as possible), have the improved system mature inside
samba and then make an independent release. Maybe as the very
last step externalize the source tree.

...Just like for talloc, tevent, tdb, ...
We have recently even decided to not externalize the code
repositories of these three libraries, even though at least
some of them can be considured mature enough and all of them
are released separately and shipped with many linux distros.

I think this approach would also have given you much more and
earlier feed-back and contributions by samba-developers. And
I don't buy the argument that externalizing makes it easier
for others to contribute. I don't believe this.

I really think it is a pity that you have chosen to go that
other path. And we should at least keep a complete copy
inside samba. (The alternative with git submodules and
copying the code into the tarballs might work, but in all
our previous attempts submodules did not work very well
so we dropped them.)

Well, it may be too late since this discussion has been
started or lead 4 months ago, but I still wanted to express
my concerns.

Again, don't get me wrong: This is great work technically!
I just have my problems with the approach and externalization.

Cheers - Michael

On 2013-08-13 at 15:55 +0200, Andreas Schneider wrote:
> On Tuesday 09 July 2013 16:35:10 Andreas Schneider wrote:
> > Hello samba-technical,
> > 
> > in the Samba project we have some wrapper we link against each executable
> > and library to be able to run 'make test'. As you might know I've been
> > working to get uid_wrapper [1], nss_wrapper [2] and socket_wrapper [3]
> > working as libraries you can load into any application using LD_PRELOAD
> > (man ld.so). If you can preload one of these libraries you can use it with
> > whatever project you want and you can create tests with optimized binaries.
> > 
> > To get it working I needed to improve the wrappers and also add new
> > important features. The biggest feature in nss_wrapper is that it provides
> > name resolution using its own hosts file now. So you can call getaddrinfo()
> > to resolve hosts in socket_wrapper. socket_wrapper got a destructor to
> > cleanup UDP socket files. uid_wrapper still needs work, to make sure that
> > it is thread safe.
> 
> I just wanted to give an update.
> 
> nss_wrapper supports new functions in the meantime:
> 
> getnameinfo()
> gethostname() (can be set with a env variable)
> gethostbyaddr_r()
> gethostbyname_r()
> 
> I've correctly implemented uid changing which also has support for threading 
> in uid_wrapper. I haven't written any threading tests yet but it should work. 
> 
> You can find the changes in my working tree:
> 
> http://git.cryptomilk.org/users/asn/uid_wrapper.git/log/?h=thread
> 
> 
> 
> 	-- andreas
> 
> -- 
> Andreas Schneider                   GPG-ID: F33E3FC6
> Samba Team                             asn at samba.org
> www.samba.org
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 215 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20131120/4ace7fa1/attachment.pgp>