[ntp:hackers] new config parsing code
mayer at ntp.isc.org
Thu Apr 26 04:59:50 PDT 2007
Sachin Kamboj wrote:
> Basically I'd have to work quite hard to find these tools for Windows.
> Bison *is* available with cygwin. There is also a standalone port of bison
> on windows that does not require cygwin. So bison is cross platform and
> readily available.
> Besides you only need it if you decide to change keywords or the
> configuration grammar. For everything else, you can use the generated files.
I agree. For me I can just log into pogo and make the changes. I just
hate having to have a bunch of additional tools for this. Having had to
grapple with yacc I want to avoid it! And that's even after I met the
yacman himself! You have no idea what I needed to do to build Kerberos
(KfW) on Windows!
>> did have something for yacc on VMS at one time but requiring these kinds
>> of tools stinks these days.
> My rule is to always use the best tool for the job. I could have written a
> parser by hand, but that would have been only marginally better than the
> existing configuration code and perhaps not even that. It would still
> require a lot of effort to make changes to the configuration code.
No you don't want to write your own parser if you can avoid it. That's
not just a school project, that's a major undertaking.
> Alternatively, I could have written a completely new and improved parser
> generator but that would be reinventing the wheel for very little gain.
> Instead I chose to use a mature and commonly used tool that's perfect for
> the purpose of parsing configuration code.
> Years ago this was the common tool for
>> parsers but if you want a language that runs on almost everything, I
>> would have chosen perl.
> To the best of my knowledge perl does not have a built in tool for creating
> LR parsers. There are perl packages that you can download for building
> parsers. However (a) few, if any, computers are likely to have these
> packages installed by default and (b) bison is much more mature than
> anything that might be available with perl.
Somehow parser languages don't really seem to have advanced. I never
looked to perl for parser packages.
> Also I would rather stay away from the horrible kludge of a programming
> language that perl is :-)
Agreed, but I use it because it's so widely available and most people
know it. My preference for years was TCL.
> This is okay for a student project but we are
>> way beyond that and it needs to be something that can be easily
>> supported and easily modifiable.
> We will not be modifying or supporting bison in any way. We will only be
> supporting the generating parser and I am sure I can vouch for that. One of
> my aims in rewriting the configuration code has been to separate the
> building of the parse tree from the actual configuration of ntp daemon
> itself. Hence, the parser should be easy to modify/change and support if
> needed since most of the support will not involve making any changes to the
> parsing code.
I'm sure it's easy enough. I'm not intending to make changes until I'm
sure that we have everything stable as a package. This is the time that
the niggedly little details start to show up!
> I don't like the choice but then nobody
>> asked me.
> Well, what would you rather have me use? I am sure it won't be too much
> effort to convert the code from using bison to whatever tool you might like
> to use since it would only require modifying a context-free grammar.
Well if I had been your advisor I would probably have done the same as
Dave probably did: Give you some possibilities and let you choose your
own tools so I'm sure it wouldn't have turned out any differently.
Well if you are interested in this subject take a look at BIND 9's
parser code which is written in C! Part of the build steps includes
building a binary (lib/dns/gen) that runs that generates the necessary
code to include in the build. Take a look at the libcfg code for
details. I don't expect you to use this code of course but I thought you
might be interested.
More information about the hackers