David Young
2008-04-29 05:38:36 UTC
I have refactored ifconfig to get rid of many global variables
and to improve extensibility. Please apply the patch,
ftp://cuw.ojctech.com/users/netbsd-81aa8ffc/ifconfig.patch, and test!
I have lightly tested IPv4, IPv6, 802.11, tunnel, and media configuration.
I especially need your help to test AppleTalk, ISO, carp(4), agr(4),
and vlan(4) configuration.
*** Details ***
In the extensible ifconfig, a directed graph of argument-matching objects
(match objects) expresses the set of feasible ifconfig statements[1].
Each match object matches a command-line argument; each path through the
match-object graph from an initial match object (selected by the flags)
to a terminal object is a sentence in ifconfig's language.
In principle, the match-object graph can be modified at run-time by, for
example, loading a dynamic library. In this way, ifconfig can be extended
to handle new configuration statements. Hence "extensible ifconfig".
In current practice, the graph is statically initialized.
Today, there are five classes of match object, each class recognizing
a different lexical category:
piface: match an interface name, xxxNN
paddr: match an IPv4, IPv6, ISO, AppleTalk, or link-layer address
pkw: match a keyword and use it to select the next match object
pinteger: match an integer
pstr: match a string
There are two special match objects that match no tokens:
pbranch: try each of zero or more match objects in turn; backtrack
on failure, quit on success
pterm: matches the end of the command line
A match object may be labelled with "exec" routines. Exec routines
provide the ifconfig argument's semantics.
ifconfig operates in two phases, parse and execute. In the parse phase,
match objects match command-line arguments, extracting information from
each argument, such as an IP addresses and prefix length, and storing it
in property dictionaries. The property dictionaries provide environment
variables for the execute phase, when ifconfig runs matching object's
exec routines.
Dave
[1] The idea to use a graph of argument-matching objects to make an
extensible parser comes from Chris Hopps.
and to improve extensibility. Please apply the patch,
ftp://cuw.ojctech.com/users/netbsd-81aa8ffc/ifconfig.patch, and test!
I have lightly tested IPv4, IPv6, 802.11, tunnel, and media configuration.
I especially need your help to test AppleTalk, ISO, carp(4), agr(4),
and vlan(4) configuration.
*** Details ***
In the extensible ifconfig, a directed graph of argument-matching objects
(match objects) expresses the set of feasible ifconfig statements[1].
Each match object matches a command-line argument; each path through the
match-object graph from an initial match object (selected by the flags)
to a terminal object is a sentence in ifconfig's language.
In principle, the match-object graph can be modified at run-time by, for
example, loading a dynamic library. In this way, ifconfig can be extended
to handle new configuration statements. Hence "extensible ifconfig".
In current practice, the graph is statically initialized.
Today, there are five classes of match object, each class recognizing
a different lexical category:
piface: match an interface name, xxxNN
paddr: match an IPv4, IPv6, ISO, AppleTalk, or link-layer address
pkw: match a keyword and use it to select the next match object
pinteger: match an integer
pstr: match a string
There are two special match objects that match no tokens:
pbranch: try each of zero or more match objects in turn; backtrack
on failure, quit on success
pterm: matches the end of the command line
A match object may be labelled with "exec" routines. Exec routines
provide the ifconfig argument's semantics.
ifconfig operates in two phases, parse and execute. In the parse phase,
match objects match command-line arguments, extracting information from
each argument, such as an IP addresses and prefix length, and storing it
in property dictionaries. The property dictionaries provide environment
variables for the execute phase, when ifconfig runs matching object's
exec routines.
Dave
[1] The idea to use a graph of argument-matching objects to make an
extensible parser comes from Chris Hopps.
--
David Young OJC Technologies
***@ojctech.com Urbana, IL * (217) 278-3933 ext 24
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
David Young OJC Technologies
***@ojctech.com Urbana, IL * (217) 278-3933 ext 24
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de