Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 16 Apr 2004 02:34:57 -0700
From:      Luigi Rizzo <luigi@FreeBSD.org>
To:        Eivind Eklund <eivind@FreeBSD.org>
Cc:        cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/net if.c route.c rtsock.c
Message-ID:  <20040416023457.A12665@xorpc.icir.org>
In-Reply-To: <20040416090520.GA1194@FreeBSD.org>; from eivind@FreeBSD.org on Fri, Apr 16, 2004 at 09:05:20AM %2B0000
References:  <200404160814.i3G8EYpj071288@repoman.freebsd.org> <20040416090520.GA1194@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 16, 2004 at 09:05:20AM +0000, Eivind Eklund wrote:
...
> >               strlcpy(ifp->if_xname, new_name, sizeof(ifp->if_xname));
> > -             ifa = TAILQ_FIRST(&ifp->if_addrhead);
> > +             ifa = ifaddr_byindex(ifp->if_index);
> 
> Given that all of the changes in this commit end of the form
> ifaddr_byindex(ifp->if_index), I'd suggest an abstraction might be in
> order.  Something like
> 
> #define ifp2ifaddr(p) ifaddr_byindex((p)->if_index)
> 

ifaddr_byindex() is already a macro, so i'd rather not have the
double indirection.

Besides, in an ideal world, we could store ifindexes instead of
ifp's in many places (routing entries, ifaddrs) which would
considerably reduce the complexity of locking, refcounting and
garbage collection.

> in order to isolate this case (which, as you say, can be implemented
> several ways).  I'm not sure ifp2ifaddr is a good name - that was just
> the first that came to mind.

Speaking of names, i am still unclear if ifaddr_byindex()
is meant to give you only the link-level address of the interface,
or the entire list of addresses associated to the interface
(which does occur, but only as an accident)

	cheers
	luigi



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