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
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 enum_list *enum_list;
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
More information about the samba-technical