common lpcfg_ as a shim to allow greater code sharing
obnox at samba.org
Tue Oct 11 15:33:36 MDT 2011
thanks for proposing your patches here.
I did not yet manage to look at them thoroughtly
(hope to find the time in the next couple of
days), but a couple comments up front:
Andrew Bartlett wrote:
> Metze, Michael
> At SDC I spoke about my idea to move the source4 loadparm code into
> 'common', so as to allow common code to be written against the lpcfg_*()
> functions. In turn, these calls can be directed to either loadparm
> system by calling loadparm_init() or loadparm_init_s3() as appropriate.
Yeah. Without knowing the details yet, I don't like the idea of
moving the s4 lp code to common as a start, as you will remember
from our discussion at the sdc. My ideal procedure would be to
change the s3 and s4 loadparm code until the common pieces are
identical and can be moved to common. I also have a couple of
more concrete ideas for steps into that direction. But
practically, I will probably not find the time to complete this very
soon. So I will look at your proposed patches and also see to what
extent I can still implement my ideas on top of that. :-)
> I've prepared a branch with my patch proposal. It does not include the
> changes to the autoconf build system, because I only wish to change that
> once I have a real-world user for that code, and this has taken a little
> longer to prepare than I expected.
No problem with that.
> I also wish to address Volker's concern about the build-time
> perl dependency before I make any further changes to the
> autoconf build.
Er, that sounds nice, but what was this?
> The changes are in this branch:
> As I make clear in the commit, this is not an attempt to define once and
> for all a common loadparm. This is just a move of the files, and the
> minimum work required to enable to result to compile in both build
> systems. The power of the loadparm_init_s3() shim is shown well by the
> new vfs_dfs_samba4 module, and I want to enable other code to use this
> feature while we continue the slow merge task.
Sounds reasonable so far. But I would appreciate if you gave me a
couple of more days to review.
Cheers - Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 206 bytes
Desc: not available
More information about the samba-technical