Of challenges in loadparm

[Michael Adam]

Hi Andrew,

Andrew Bartlett wrote:
> 
> I guess I don't really see why the 'loop' here is an issue, given the
> separate build stages involved.  As to the significance of leading
> spaces, aside from being a convention that has worked quite well for
> Samba for quite some time, I don't mind if it's changed to a CPP token
> that is defined away. 

Yeah, with a token I would feel more comfortable. It is more
explicit. It is so easy for the human eye (especially mine) to
overlook a little whitespace here and there.

Apart from that it is a matter of personal taste probably,
or paranoia, that I don't like to have some script parse
the C file to generate headers that the C file (and other files)
then include. I just feel more comfortable with having to
explicitly maintain prototype headers. But again, this is
a personal thing, I can't really give better arguments right now.

> I would like to see this stage extended to restore automatic prototype
> generation of loadparm functions, in the interim before a more grand
> scheme can be achieved.  Doing so would make changes in this area much
> less error prone (I'm pretty sure there are both missing and extra
> prototypes at the moment). 

Well, I think I will start out with creating dedicated header
file(s) for the param/ modules.

> On Thu, 2011-07-21 at 13:49 +0200, Michael Adam wrote:
> > 
> > I just wanted to let you know that I am planning to add something
> > to s3 loadparm soon. I have added something called libsmbconf
> > some time ago to support registry configuration in samba3
> > loadparm. And it is already used for registry config there.
> > See process_registry_shares() and process_registry_service().
> > This already implements the layer separation of parsing and
> > implementing/activating the changes. The libsmbconf also has a
> > text backend that uses the param.c parser from loadparm. I will
> > add a "flat" backend to libsmbconf that will parse the whole tree
> > of includes, keeping track of config files/sources. The resulting
> > array of smbconf sections will ideally not have includes any more but
> > will be completely expanded. 
> 
> Have you seen the code Jelmer did for generic parameter handling?  It's
> not very much, nor it is much used, but it's in lib/util/paramlist.c and
> lib/util/paramlist.h and you might want to take a look at it. 

Thanks for the hint!

> > The result will then be processed
> > in the same way as process_registry_shares() is currently doing.
> 
> The big issue I see with this is the immediate application of loadparm
> variables.  But given we have ways of setting the log level on the
> command line, removing the immediate application would certainly make
> this much less delicate area of code, if we think we can make that
> change.

I don't quite get yet, what you mean here. Maybe I will
understand soon. :-)

> > As a start, also working towards a unification of the code,
> > I am adding a loadparm context to s3 loadparm.c to carry all
> > those nasty global variables.
> 
> If you do move towards a context here, if it could be the same one
> already used in Samba4 it would be very helpful.  In particular, being
> able to pass it to the lpcfg_ functions would be very useful.  That is,
> a way to split the lpcfg_ functions off from the rest of the source4
> loadparm, and get a context from a function like loadparm_init_s3() that
> similarly has few deps would be really useful.   (The best course of
> action here might actually be to split these parts of s4's loadparm into
> some common code). 

Yes, the plan was to start adding the context (as a gloabal
variable for a start) and start using it. This would first
collect all the relevant globals from s3 loadparm.c. Then I would
morph the code and the structure to become more similar to what
the s4 loadparm does (passing the context around as extra
argument, allocating it etc...). If I find stuff in s4 that I think
should be changed to resemble stuff in s3, I might do/discuss this.
Eventually, when the two systems have become similar/equal
enough, I would split out common code. (Not vice versa.)

But as I said, I also plan to go a step further in s3 (for a
start): I would like to move the parsing logic, also the keeping
track of file list and timestamps, into a backend for libsmbconf.
Then the loadparm code iteself would get greatly simplified.
(The file list and all the parsing state variables would vanish
from the loadparm context and it would get an smbconf context
instead.) I guess this change would be s3-only in the beginning,
but could/should be moved to common code if it works out nicely.

> Whatever we do here, I would ask that you either make the same change to
> the s4 loadparm, or do more work to integrate the two systems before you
> diverge them again.  The two systems are getting much closer, and it
> would be unfortunate to diverge them again before we get a single
> system. 

Yes, one goal is certainly to eventually be able to factor out
common code from s3 and s4 loadparm. In the mode I am typically
workin in, this means that I will morph the s3 loadparm code
before I can achieve this (and possibly also the s4 loadparm code
to some extent).

I will start with it and discuss when there is doubt about the
right approach.

Cheers - Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20110729/f80c8e24/attachment.pgp>