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

From: Bruce M Simpson (bms_at_spc.org)
Date: 11/30/03

  • Next message: Robert Watson: "Re: ifconfig(8) refactoring -- YACC grammar now online" 
    Date: Sun, 30 Nov 2003 19:42:20 +0000
To: Robert Watson <rwatson@freebsd.org>

    On Sun, Nov 30, 2003 at 02:20:50PM -0500, Robert Watson wrote:
    > if_type seems like it will work for high level classes of interfaces, but
    > something more fine-grained will be required for interfaces that implement
    > multiple classes or subclasses (i.e., 802 generally, and also 802.11b).

    The idea just now is we look at if_media if we need to get specific with
    physical interfaces.

    tap would seem to be missing from my list, actually; I note it's used
    to provide VMware support in the absence of Netgraph, amongst other things.

    > Or likewise, tap interfaces might implement 802 generally, but also
    > if_tap-specific primitives. Do we need to probe by-name for capabilities
    > using interface ioctls, or return a "list" of implemented
    > interfaces/classes to allow things to be a bit more multidimensional?

    That might work well, actually -- I already added a MIB to rtsock to deal
    with our lack of reporting multicast group memberships, I see no reason
    not to add one to enumerate loaded interface classes.

    OTOH, for the 'could load kld' case, this falls down, until the instance
    is created, either through cloning or completing ifattach() for a physical
    interface -- but if CREATE is a separate operation this isn't a problem,
    it is a problem if we want to say something like this in one go:-

      ifconfig gif0 create tunnel 1.2.3.4 5.6.7.8 10.0.0.1 10.0.0.2

    Then you do need a means for the ifconfig instance to ask gif0 if it speaks
    'tunnel-ese' once it's loaded.

    I have to find an abstraction to comfortably deal with this stacking of
    properties/methods, simple polymorphism (a la Java 'implements interface')
    springs to mind.

    BMS
    _______________________________________________
    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: Robert Watson: "Re: ifconfig(8) refactoring -- YACC grammar now online"

    Relevant Pages

    • Re: ifconfig(8) refactoring -- YACC grammar now online
      ... > if_type seems like it will work for high level classes of interfaces, ... > something more fine-grained will be required for interfaces that implement ... not to add one to enumerate loaded interface classes. ... Then you do need a means for the ifconfig instance to ask gif0 if it speaks ...
      (freebsd-hackers)
    • Re: ifconfig(8) refactoring -- YACC grammar now online
      ... >> What I've thinking about a lot is to make the networking system and ... > This is one way to do it without having to change struct ifnet. ... if_type seems like it will work for high level classes of interfaces, ... something more fine-grained will be required for interfaces that implement ...
      (freebsd-hackers)
    • Re: ifconfig(8) refactoring -- YACC grammar now online
      ... >> What I've thinking about a lot is to make the networking system and ... > This is one way to do it without having to change struct ifnet. ... if_type seems like it will work for high level classes of interfaces, ... something more fine-grained will be required for interfaces that implement ...
      (freebsd-arch)