On Mon, 2006-08-28 at 17:18 -0400, Sagun Shakya wrote:
> Thank you for you comments, Seb. My responses are inline.

FYI, my usr/src/lib/libdlpi comments are coming shortly.

> Sebastien Roy wrote:
> 
> >usr/src/cmd/cmd-inet/usr.sbin/ifconfig/ifconfig.c
> >
> >3649: why not use IF_NAMESIZE (the standard maximum interface name
> >      constant)?
> >  
> >
> Using a standard constant makes more sense. I've changed it to be a 
> IF_NAMESIZE.

On the other hand, if you'd rather have a libdlpi specific constant,
that's fine, but instead of setting it to 32 in libdlpi.h, I'd set it to
IF_NAMESIZE (or LIFNAMSIZ).

> >3659, 3774: A comment is warranted regarding why this needs to be done.
> >
> Before adding comments, I wanted to get opinions about making 
> dlpi_detach a flag to dlpi_open() instead of providing it as a 
> Consolidation private interface. 

You mean like a DLPI_NOATTACH flag to dlpi_open()?

> Right now the only consumer of dlpi_detach is ifconfig.c, in order to 
> make this change the function signature of plumb_one_device() would need 
> to be changed as well. This would also simplify plumb_one_device() and 
> inetplumb().
> 
> static void
> -plumb_one_device(dlpi_if_attr_t *diap, int ip_fd, int af)
> *+plumb_one_device(int af)*
> 
> Also, since dlpi_attach() is not explicitly called by any applications 
> there is no need to provide this api as a consolidation private interface.

That sound fine to me, but in reality, I'd like to get to the bottom of
why the ip module needs to drive this attach.  I think it would be fine
if dlpi_open() did the attach and the ip module were modified to expect
an already attached DLPI style-2 device...  Anyway, that part can be
fixed as a separate RFE or bug fix.

Thanks!
-Seb



Reply via email to