[PATCH] Auto-generate param_functions.c at build time

Nadezhda Ivanova nivanova at samba.org
Tue Jan 14 14:12:47 MST 2014


Hi guys,
I've been reading this discussion, and looking at some of the
patches... In my humble opinion, when something - especially a big set of
patches - is left to ripen, it risks being put off to the point of bring
unuseable, or by the time we actually decide to use it it may be very
difficult to merge. I agree that we needed to see the "big picture", but
this is work that can fix problems that have been there for a while, and
while we are all busy, it deserves our consideration, especially given that
Garming will not be working on this forever. Just my 2 cents...

Regards,
Nadya


On Tue, Jan 14, 2014 at 5:23 PM, Michael Adam <obnox at samba.org> wrote:

> Hi Andrew and Garming,
>
> it is good to see that you are making progress on this!
>
> Next step would be to generate the param_table right?
> And then to not have mkparamdefs generate the headers
> from the generated param_functions but have the script
> generate_param.py generate them in one go. Correct?
>
>
> I will try hard to find the time to look very closely
> at the patches and the resulting code in the next days.
>
> It is good to move towards a central place of definition of
> conf parameters. But I do second Volker's request to not rush
> the patchset into master, and let it ripe a bit in a private
> tree, because it is very important that a few people understand
> it properly... :-)
>
> The last step, generating the headers from the FN macros
> etc, had the positive effect to remove one (or so) place to
> touch when adding a parameter, but for me at least the changes
> done at that time had the negative effect that they made it
> much more difficult to understand the loadparm code.
> This is probably mainly related to the splitting between
> s4- and s3-loadparm, and I hence think it is very important
> to refactor the code to be able to share loadparm.
> I would like to be assured that this goal (which I would have
> loved to see reached before generating the code) is not made
> much more difficult to achieve by the new autogeneration-changes.
>
> Cheers - Michael
>
>
> On 2014-01-15 at 02:22 +1300, Andrew Bartlett wrote:
> > On Tue, 2014-01-14 at 18:15 +1300, Garming Sam wrote:
> > > This is a patch that goes on top of the tree that Andrew Bartlett
> posted
> > > earlier.
> > >
> > > Right now, the script only performs the generation for the
> > > param_functions.c file, however, it should eventually support
> generation
> > > of some of the other files dependent on it.
> > >
> > > It also moves the final remaining special cases away from
> > > param_functions so they can be noted and dealt with appropriately.
> > >
> > > As well as successfully building,  the output was sorted and compared
> > > with the original manually created file to check that it was
> consistent.
> > >
> >
> > Thanks Garming,
> >
> > One thing we need to fix up is the comment at the top of
> > lib/param/loadparm.c and source3/param/loadparm.c:
> >
> >  * To add a parameter:
> >  *
> >  * 1) add it to the global or service structure definition
> >  * 2) add it to the parm_table
> >  * 3) add it to the list of available functions (eg: using
> > FN_GLOBAL_STRING())
> >  * 4) If it's a global then initialise it in init_globals. If a local
> >  *    (ie. service) parameter then initialise it in the sDefault
> > structure
> >
> > It needs to be something like:
> >
> >  * To add a parameter:
> >  *
> >  * 1) add it to the XML documentation in docs-xml/smbdotconf
> >  * 2) add it to the parm_table in lib/param/param_table.c
> >  * 3) If it's a global then initialise it in init_globals. If a local
> >  *    (ie. service) parameter then initialise it in the sDefault
> > structure
> >
> > The new way of adding an smb.conf parameter will be strange to some
> > developers who haven't followed this closely, so we need to give them as
> > many clues as possible.  Perhaps also put /* autogenerated from the XML
> > documentation in docs-xml/smbdotconf by script/generate_param.py */ at
> > the top of the generated files and just before the #include.
> >
> > Thanks,
> >
> > Andrew Bartlett
> > --
> > Andrew Bartlett                       http://samba.org/~abartlet/
> > Authentication Developer, Samba Team  http://samba.org
> > Samba Developer, Catalyst IT
> http://catalyst.net.nz/services/samba
> >
> >
>


More information about the samba-technical mailing list