| 1 | libsamba-hostconfig
|
|---|
| 2 | -------------------
|
|---|
| 3 |
|
|---|
| 4 | This directory contains "libsamba-hostconfig".
|
|---|
| 5 |
|
|---|
| 6 | The libsamba-hostconfig library provides access to all host-wide configuration
|
|---|
| 7 | such as the configured shares, default parameter values and host secret keys.
|
|---|
| 8 |
|
|---|
| 9 |
|
|---|
| 10 | Adding a parameter
|
|---|
| 11 | ------------------
|
|---|
| 12 |
|
|---|
| 13 | To add or change an smb.conf option, in general you only have to add
|
|---|
| 14 | the documentation to docs-xml/smbdotconf, or change it.
|
|---|
| 15 | In addition to that, if special defaults are needed, the functions
|
|---|
| 16 | loadparm_init() in lib/param/loadparm.c and/or init_globals() in
|
|---|
| 17 | source3/param/loadparm.c need to be adapted accordingly.
|
|---|
| 18 | The rest is generated for you.
|
|---|
| 19 |
|
|---|
| 20 | It is important to get the attributes right in the <samba:parameter ...>
|
|---|
| 21 | tag of the xml files. These determine the details of the generated code.
|
|---|
| 22 |
|
|---|
| 23 | - Supported attributes are name, context, type, constant, function,
|
|---|
| 24 | generated_function, synonym, parm, enumlist, handler, and deprecated.
|
|---|
| 25 | - Supported contexts are 'G' (for global) and 'S' (for share).
|
|---|
| 26 | - Supported types are boolean, boolean-rev, boolean-auto, list,
|
|---|
| 27 | cmdlist, string, ustring, char, integer, bytes, octal, and enum.
|
|---|
| 28 |
|
|---|
| 29 |
|
|---|
| 30 |
|
|---|
| 31 | Using smb.conf parameters in the code
|
|---|
| 32 | -------------------------------------
|
|---|
| 33 |
|
|---|
| 34 | Call the lpcfg_*() function. To get the lp_ctx, have the caller pass
|
|---|
| 35 | it to you. To get a lp_ctx for the source3/param loadparm system, use:
|
|---|
| 36 |
|
|---|
| 37 | struct loadparm_context *lp_ctx = loadparm_init_s3(tmp_ctx, loadparm_s3_helpers());
|
|---|
| 38 |
|
|---|
| 39 | Remember to talloc_unlink(tmp_ctx, lp_ctx) the result when you are done!
|
|---|
| 40 |
|
|---|
| 41 | To get a lp_ctx for the lib/param loadparm system, typically the
|
|---|
| 42 | pointer is already set up by popt at startup, and is passed down from
|
|---|
| 43 | cmdline_lp_ctx.
|
|---|
| 44 |
|
|---|
| 45 | In pure source3/ code, you may use lp_*() functions, but are
|
|---|
| 46 | encouraged to use the lpcfg_*() functions so that code can be made
|
|---|
| 47 | common.
|
|---|
| 48 |
|
|---|
| 49 |
|
|---|
| 50 | How does loadparm_init_s3() work?
|
|---|
| 51 | ---------------------------------
|
|---|
| 52 |
|
|---|
| 53 | loadparm_s3_helpers() returns a initialised table of function
|
|---|
| 54 | pointers, pointing at all global lp_*() functions, except for those
|
|---|
| 55 | that return substituted strings (% macros). The lpcfg_*() function
|
|---|
| 56 | then calls this plugged in function, allowing the one function and
|
|---|
| 57 | pattern to use either loadparm system.
|
|---|
| 58 |
|
|---|
| 59 |
|
|---|
| 60 | There is a lot of generated code, here, what generates what?
|
|---|
| 61 | ------------------------------------------------------------
|
|---|
| 62 |
|
|---|
| 63 | The regular format of the CPP macros in param_functions.c is used to
|
|---|
| 64 | generate up the prototypes (mkproto.pl, mks3param_proto.pl), the service
|
|---|
| 65 | and globals table (mkparamdefs.pl), the glue table (mmks3param.pl) and
|
|---|
| 66 | the initilisation of the glue table (mks3param_ctx_table.pl).
|
|---|
| 67 |
|
|---|
| 68 | I have tried combining some of these, but it just makes the scripts more
|
|---|
| 69 | complex.
|
|---|
| 70 |
|
|---|
| 71 | The CPP macros are defined in and expand in lib/param/loadparm.c and
|
|---|
| 72 | source3/param/loadparm.c to read the values from the generated
|
|---|
| 73 | stuctures. They are CPP #included into these files so that the same
|
|---|
| 74 | macro has two definitions, depending on the system it is loading into.
|
|---|
| 75 |
|
|---|
| 76 |
|
|---|
| 77 | Why was this done, rather than a 'proper' fix, or just using one system or the other?
|
|---|
| 78 | -------------------------------------------------------------------------------------
|
|---|
| 79 |
|
|---|
| 80 | This was done to allow merging from both ends - merging more parts of
|
|---|
| 81 | the loadparm handling, and merging code that needs to read the
|
|---|
| 82 | smb.conf, without having to do it all at once. Ideally
|
|---|
| 83 | param_functions.c would be generated from param_table.c or (even
|
|---|
| 84 | better) our XML manpage source, and the CPP macros would instead be
|
|---|
| 85 | generated expanded as generated C files, but this is a task nobody has
|
|---|
| 86 | taken on yet.
|
|---|
