Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 22 Apr 2004 08:44:51 -0700
From:      Brooks Davis <brooks@one-eyed-alien.net>
To:        Andre Oppermann <andre@freebsd.org>
Cc:        net@freebsd.org
Subject:   Re: RFC: if_clone overhaul
Message-ID:  <20040422154450.GA2695@Odin.AC.HMC.Edu>
In-Reply-To: <4087D314.F5ED2344@freebsd.org>
References:  <20040421042453.GA8866@Odin.AC.HMC.Edu> <4087D314.F5ED2344@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--jRHKVT23PllUwdXP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Apr 22, 2004 at 04:13:40PM +0200, Andre Oppermann wrote:
> Brooks Davis wrote:
> >=20
> > Please test/review the following patch to the network interface cloneing
> > code.  This code is a major overhaul of the cloning infrastructure.
> >=20
> > The significant include:
> >  - Split the code out into if_clone.[ch].
> >  - Locked struct if_clone.  Derived from work by Maurycy
> >    Pawlowski-Wieronski <maurycy at fouk.org>
> >  - Add a per-cloner match function rather then simply matching names of
> >    the form <name><unit> and <name>.
> >  - Use the match function to allow creation of <interface>.<tag>
> >    vlan interfaces.  The old way is preserved unchanged!
> >  - Also the match function to allow creation of stf(4) interfaces named
> >    stf0, stf, or 6to4.  This is the only major user visiable change in
> >    that "ifconfig stf" creates the interface stf rather then stf0 and
> >    does not print "stf0" to stdout.
> >  - Allow destroy functions to fail so they can refuse to delete
> >    interfaces.  Currently, we forbid the deletion of interfaces which
> >    were created in the init function, particularly lo0, pflog0, and
> >    pfsync0.  In the case of lo0 this was a panic implemenation so it
> >    does not count as a user visiable change. :-)
> >  - Since most interfaces do not need the new functionality, an family of
> >    wrapper functions, ifc_simple_*(), were created to wrap old style
> >    cloner functions.
> >  - The IF_CLONE_INITIALIZER macro is replaced with a new incompatable
> >    IFC_CLONE_INITALIZER and ifc_simple consumers use IFC_SIMPLE_DECLARE
> >    instead.
> >=20
> > TODO:
> >  - Integrate vlan changes into /etc/rc* (add support for interfaces with
> >    '.' in their name).
> >  - Document new vlan syntax in vlan(4).
>=20
> Looks good and I like it! ;-)
>=20
> Some comments:
>=20
>  o in net/if_clone.h you can remove the 3rd Regents copyright clause.
>  o in net/if_clone.c you can remove the 3rd Regents copyright clause.

Done in perforce.

>  o in net/if_clone.h, is ## really a legal character in variables?
>    Looks strange for sure!

That's the concatenation operator for cpp macros.  While it's not
stricly necessicary to use a unique variable name per driver since the
variable is static, it's still a good idea in general.  This lets me do
that (it's also why the input is unquoted).

>=20
>  o how far does the cloning code scale?  I'm asking because with the
>    work on the l2tp stuff you'll get machines with possibly 10'000
>    or more ppp over l2tp connections acting as LAC.

The only scaling issue I can think of is that it uses a linearly scanned
bitmap of units to handle unit allocation.  You could presumably
optimize this into some sort of a tree if you had poor performance and
sparce allocation.  You could also obtain some optimization benefits by
using longs (native word size ints) instead of chars.

-- Brooks

--=20
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4

--jRHKVT23PllUwdXP
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAh+hyXY6L6fI4GtQRAqoWAKCa8VGpdT/BOErglqPlTCQSmPT9cwCgh4/r
7P9mVfBBX6YkUTYQvyJcblE=
=ytzh
-----END PGP SIGNATURE-----

--jRHKVT23PllUwdXP--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040422154450.GA2695>