XML documentation syntax, code generation and renaming lp_ functions to match parameter names.

Andrew Bartlett abartlet at samba.org
Sun Feb 2 16:47:12 MST 2014


On Mon, 2014-02-03 at 00:25 +0100, Michael Adam wrote:
> Hi Garming,
> 
> On 2014-02-03 at 10:41 +1300, Garming Sam wrote:
> > 
> > >One other question about metadata:
> > >Could you provide a list of metadata entries that you
> > >added and their precise meaning?
> > >So far I saw "function", "synonym", "generated_function",
> > >"constant", "parm"
> > 
> > function corresponds to what function name is generated i.e. lp_xxxx
> > and lpcfg_xxxx. In the case where no name is specified, the
> > parameter name with underscores instead of spaces will be generated
> > automatically (unless it's marked not to generate).
> > 
> > generated_function = "0" if you don't want to generate an lp
> > function from this parameter. This is basically for special cases,
> > which may happen where there is some kind of conflict currently.
> > 
> > synonym is currently marked for any synonyms, but normal synonyms do
> > not usually have an xml page, so this only actually appears for
> > inverted synonyms currently. Currently marking a synonym means that
> > no lp function is also generated.
> > 
> > constant refers to whether or not the parameter should be constant,
> > but this is actually only currently used for strings. Constant in
> > this case indicates whether or not substitutions occur with the
> > string, I believe.

That is correct, and it also marks the return type of the C function as
'const'. 

> > parm, I was actually never entirely sure of. Some of the functions
> > are in the form FN_XX_PARM_XX and they take a different parameter,
> > share_params (instead of an integer which corresponds to the service
> > index). If anyone could shed light on it, that would be helpful.
> > There's not actually that many of them. And they look nearly
> > obsolete in the s4 macros.

Indeed, this is an odd case.  I've never been particularly clear if this
was something we were phasing in or out, or a partial rework of this
area.  Generally I prefer a service structure to a service number, but
we need to look into this and either finish or eliminate this. 

> > But yeah, with all this metadata stuff, it's previous obvious to see
> > which things were outliers.
> 
> Thanks for the explanation!
> 
> According to my pervious mail, I have prepared a first patchset for
> pushing. It does not add any function= occurrences except for those
> where the function starts with a "_". I.e those additions of
> function metadata that can be avoided by renaming variables and FN_
> definitions. A few of the original patches also added "parm" or
> "constant" metadata: I kept that portion of the original patches
> removing the function bit. One additional change is that I split
> the patch "docs: insert meta data into enable spoolss and
> writeable for marking a synonym" into two (keeping authorship etc).
> 
> See this state in my master-param-reviewed branch:
> https://git.samba.org/?p=obnox/samba/samba-obnox.git;a=shortlog;h=master-param-reviewed
> 
> If you are OK with that I'd push these and pursue the
> renaming of the functions+variables (and encourage you to
> join in. :-)

Thanks for your work and thoughts on this.  I agree, while we are
working to clean up this area, doing the other renames makes a lot of
sense, because it isn't likely to be tidied up later, so I fully support
doing it now. 

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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140203/0bf03edc/attachment.pgp>


More information about the samba-technical mailing list