ifconfig(8) refactoring -- YACC grammar now online

Andre Oppermann andre at freebsd.org
Sun Nov 30 04:12:50 PST 2003


Bruce M Simpson wrote:
> 
> Hi all,
> 
> As per Sam's suggestion, I've been working on refactoring ifconfig(8),
> which has grown increasingly large and unwieldy. Part of the effort has
> been to get a handle on all of the options we currently support; so I've
> written a YACC grammar for it.
> 
> This is my first serious bit of work with YACC so I'd appreciate any
> feedback you can give.
> 
> I've uploaded the grammar, makefile, and all the EPS files, here:-
>         http://people.freebsd.org/~bms/dump/nifconfig/     (for browsing)
>         http://people.freebsd.org/~bms/dump/nifconfig.tgz  (tarball)
> 
> I've also generated a PDF file you can view which shows you syntax diagrams
> for each part of the parse tree. This is here:-
>         http://people.freebsd.org/~bms/dump/nifconfig/all.pdf
> 
> I can't quite seem to persuade Ebnf2ps to generate a recursive unfolding
> of all productions from argv downwards, though, that would be most helpful.
> 
> This involved rolling two ports, epsmerge and Ebnf2ps, to visualize the
> syntax graphically. I will commit these ports once the freeze as over as
> they're likely to be useful to a lot of people.
> 
> Please let me know your thoughts on this.

I think this refactoring of ifconfig is very good.  I haven't read the
yacc grammar as I have never worked with yacc before, so I can't comment
on your implementation.

What I've thinking about a lot is to make the networking system and
ifconfig sort of class-based like newbus and geom.

For example having a general ieee802-class for all interfaces which
belong into that group (10/100/1000BaseTX, WirelessLAN, etc.) would
be great.  Then there are more specific sub-classes for media-types
like 802.11 if they have properties which go further than the general
ieee802 functions.

For example the ieee802-class would implement general functionality
which is available with all ieee802 media-types like VLAN, priority
tagging, link authentication and so on.  The 802.11-class would implement
things like channel selection, operating mode, encryption keys and
so on.

Some functions in the general classes have direct representations in
the interface namespace.  For example I'd like to be able to specify
a interface in a VLAN like this:

 ifconfig fxp0.2 inet ...

which would clone fxp0 and put the cloned interface into VLAN number
two.  This works generally for all ieee802-class interfaces.

Commands for 802.11 would only be available for WLAN interfaces.

A channelized T1/E1 card like the LAN Media cards could be configured
like this:

 ifconfig lmc0/1-32

which would take E1 channels one to thirty-two into this interface.
When you have fractional bandwidth it would look like lmc0/1-4 for
256kbit.  Or make a second interface with channels 5-8 with ifconfig
lmc0/5-8.  An overlap of channels is prohibited of course. It get's
ever better with a T3/E3 interface ifconfig env0/5/1-4 which would
select channels one to four out of the fifth E1 in the E3 pipe.
Repeat that with OCx or STMx interfaces.

However the interpretation of the command line is done by the class
the interface is in.

-- 
Andre


More information about the freebsd-arch mailing list