On Thu, 2009-10-08 at 07:24 -0700, Michael Hunter wrote:
> On Thu, 08 Oct 2009 09:59:55 -0400
> Sebastien Roy <Sebastien.Roy at Sun.COM> wrote:
>
> > Thanks for the responses.
> >
> > On Wed, 2009-10-07 at 15:45 -0700, Michael Hunter wrote:
> > > seb-097 ncu_ip.c'540-582: The strategy used to figure out if a logical
> > > interface is needed or if it's the first address seems error prone and
> > > certainly not thread safe (although I'm not sure if thread safety is a
> > > concern for this function). This seems to be needed as a side-effect of
> > > the distinction between the newly introduced icfg_add_ipaddr() vs.
> > > icfg_set_addr() functions. It should be possible to fix this by defining
> > > a single icfg_add_addr() function that just does the right thing.
> > >
> > > rewritten significantly, less complex and covers add/set distinction in
> > > add_ip_address
> > >
> > > On a related note, why is one _ipaddr() and the other _addr()?
> > >
> > > We inherited libinetcfg. Ask the bad boy who wrote it?
> >
> > My point is that there is an existing convension of _addr in libinetcfg,
>
> Which makes sense since its libinetcfg, not libnetcfg.
It's not a big deal, it's just a matter of consistency. This will all
hopefully get yanked out by Brussels II (right?).
>
> > and the NWAM project is adding a conflicting convention of _ipaddr. The
> > disparate nomenclature is entirely due to the new NWAM code. I don't
> > understand the response.
>
> I didn't understand your question correctly. I've changed
> icfg_{add,remove}_ipaddr() to icfg_{add,remove}_addr();
Okay, thanks.
-Seb
