ifconfig(8) refactoring -- YACC grammar now online

[Bruce M Simpson]

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