On Thu, 08 Oct 2009 10:26:34 -0400
Sebastien Roy <Sebastien.Roy at Sun.COM> wrote:
> 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?).
Easy to do at the point of change and it is amazing how long things
live that were not expected to see the end of the day.
Yes! It should disappear with Brussels II RSN.
mph
>
> >
> > > 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
>
>
