SWAT demo

Andrew Tridgell tridge at samba.anu.edu.au
Sat Mar 14 02:00:20 GMT 1998

> Okay, I'm looking at SWAT from the 'smb.conf syntax' point of view.  If 
> at all possible, can you provide a clean demark so that changes to the 
> parsing and parameter access mechanisms won't cause too much difficulty?

the interface calls swat makes are currently:


the most important ones for swat are lp_next_parameter
and lp_do_parameter. See loadparm.c for exactly what these do.
Note that nothing in swat ties us to the current smb.conf parsing. 

> > This looks good. Please can we make sure that for every parameter that has
> > a fixed set of options we provide only a set of on/off buttons for each.
> This is adding a pseudo-enumeration type to the current stuff.  It's
> turning at the back of my mind.  In some cases we'll want to accept only
> one of the available options, in others we'll want to accept a set of
> them. 

we already have enumeration types in loadparm.c. That's how all the
enumerated stuff is handled! They were handled as integers in 1.9.17
but I changed that and added a proper enumerated type when I started
thinking about a web admin tool.

the most "tied to loadparm" function is lp_next_parameter() which
returns a pointer to a parameter structure that contains:

struct parm_struct
	char *label;
	parm_type type;
	parm_class class;
	void *ptr;
	BOOL (*special)();
	struct enum_list *enum_list;
	unsigned flags;

this structure was private to loadparm.c until last week when I made
it public by getting lp_next_parameter() to return it. I needed to do
that as the parameter passing in lp_next_parameter() was getting
unwieldy with the need for the enumerated types. 

> > Also, for parameters like "netbios resolve order" (yet to be implemented)
> > and "socket options" that have a fixed set of options could we list these
> > as a help to the administrator.

these two options are a cross between strings and a enumerated
type. Particularly "socket options" as it can't just be seen as a bit
list of on/off options. Many socket options take optional integer

That's why in the current swat socket options is a string. I don't
think that is a big problem as it is an advanced option and we just
need to get the help text ok so people can understand. I don't think
a lump of code to handle lists of enumerated and integer types in
one option is really justified.

> Part of my thinking, when considering the whole smb.conf thingumy, is that
> you should be able to ask for all available parameters and their
> acceptable values.

yep, that is exactly what lp_next_parameter() does. It allows you to
walk the list of possible parameters retrieving the types and (in the
case of enumerated types) lists of acceptable values.

>  Once the syntax is down (working on some ideas, and
> yes I'm aiming at backward compatibility), it shouldn't be too hard to
> come up with a structure to hold a definition of availalbe parameters. 
> (In fact, such a structure *could* be used to manage and edit X Resources
> and the like.)

that's exactly how swat works. swat has no real knowledge of Samba
parameters. It just walks the list offered by loadparm.c

Cheers, Andrew

More information about the samba-technical mailing list