Re: ifconfig(8) refactoring -- YACC grammar now online

From: Andre Oppermann (andre_at_freebsd.org)
Date: 11/30/03

  • Next message: Bruce M Simpson: "Re: ifconfig(8) refactoring -- YACC grammar now online" 
    Date: Sun, 30 Nov 2003 13:12:42 +0100
To: Bruce M Simpson <bms@spc.org>

    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
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
  • Next message: Bruce M Simpson: "Re: ifconfig(8) refactoring -- YACC grammar now online"

    Relevant Pages