New configuration backends for Samba 3 SoC project
avi at alkalay.net
Wed May 31 13:44:24 GMT 2006
On 5/30/06, Ming <mingwxia at gmail.com> wrote:
> If we use libelektra,we need to implement a backend in libelektra
> which probably named
> should parse the smb.file and implement a set of interface used by
> libelektra.so.Further more in order to maintain the other samba server
> part changed as few as possible to use the new configuration backend,
> We might wrap the libelektra.so interface to what smb team already
I don't think that a libelektra-smb.so (something that reads smb.conf
and expose it through Elektra key/value pairs) is usefull.
In the X.org patch we kept the xorg.conf parsing code and used it to
provide the parsed key/values. So the first time a patched X servers
runs, the key/value tree is built based on current xorg.conf file and
next times it runs configuration is being read only from the key/value
tree, and xorg.conf is not being accessed anymore.
> Yes and I'm not clear how the other parts use the smb.conf backend(all
> through lp_**?). Should we implement the new configuration backend as
> a new set of get/set interface, that will bother the other server
> part,I think.
> > Most of the lp_XXX() functions can be wrapped around
> > a simple query call. The main hurdles are smb.conf
> > variables and the include parameter.
Some functions I don't remember the name (maybe the lp_XXX() ones)
parse smb.conf and call param/param.c::pm_process() to fill internal C
structs. So an Elektra patch would reimplement the callers of
pm_process() and call it for each key/value found. The problem is that
the callers of pm_process() are spread all around Samba's source and
are of many different types. And they use as parameter a variable
called dyn_CONFIGFILE which seems overused in may places too.
More information about the samba-technical