o mark cmds/parameters to indicate they are potential arguments to a clone
operation (e.g. vlantag)
o when handling a create/clone operation do the callback on seeing the first
non-clone cmd line argument so the new device is created and can be used;
and re-setup operating state to reflect the newly created device
Reviewed by: Eugene Grosbein
MFC after: 2 weeks
mechanism
o change vlan cloning to use callback and pass all vlan parameters
on create using the new SIOCREATE2 ioctl
o update vlan set logic to match existing practice
as both have been read from the command line. Still use the callback,
but this time only to verify that both vlan and vlandev have been
found on the command line.
This should allow for control over the relative order of processing
parameters, which is needed to satisfy some caveats of the if_vlan
driver. E.g., MTU cannot be changed on a vlan interface until it's
attached to its parent.
PR: bin/94028
Reviewed by: ru
MFC after: 3 days
and "vlandev" commands can be specified in any order.
This makes the code more compact and clear as well.
Improve error check on vlan argument.
MFC after: 2 weeks
special-purpose code to display status for an interface for
state that was not address-oriented. This status reporting
was merged in to the address-oriented status reporting but
did not work for link address reporting (as discovered with
fwip interfaces). Correct this mis-merge and eliminate the
bogus kludge that was used for link-level address reporting.
o add an af_other_status method for an address family for
reporting status of things like media, vlan, etc.
o call the af_other_status methods after reporting address
status for an interface
o special-case link address status; when reporting all
status for an interface invoke it specially prior to
reporting af_other_status methods (since it requires the
sockaddr_dl that is passed in to status separately from
the rtmsg address state)
o correct the calling convention for link address status;
don't cast types, construct the proper parameter
This fixes ifconfig on fwip interfaces.
o break per-address family support out into separate files
o modularize per-address family and functional operations using
a registration mechanism; this permits configuration according
to which files you include (but beware that order of the files
is important to insure backwards compatibility)
o many cleanups to eliminate incestuous behaviour, global variables,
and poor coding practices (still much more to fix)
The original motivation of this work was to support dynamic addition
of functionality based on the interface so we can eliminate the various
little control programs and so that vendors can distribute ifconfig
plugins that support their in-kernel code. That work is still to be
completed.
o Update 802.11 support for all the new net80211 functionality; some
of these operations (e.g. list *) may be better suited in a different
program
