Xiang Samuel Zhou writes: > > If I'm reading that correctly, it doesn't even support DLPI Style 1. > > I'm hoping that's wrong, based on the description below, because it'd > > be a show-stopper of a bug. > iftop ONLY use these codes to get the mac address. For other operations on > interface, it uses functions in libpcap. > I tried to remove the codes to get mac address. it works ok in global zone > and non-global exclusive zone. Further, if I remove all the definations in > dlpi.h and do not include dlpi.h in source code, the compiled binary works > good for exclusive zone and vanity naming.
I think we're getting down below architectural review. If you can send me a pointer to the original code and your changes, I'll look at it to see if there are problems here. The architectural issue, though, is that DLPI applications need to support both Style 1 and Style 2 in order to work properly on Solaris, and should also support vanity naming to avoid confusion. How you go about achieving that is separate. > > None should be needed if you're not dealing with the /dev entries > > directly, and are instead going through the normal system libpcap. > Right, could it be ok to fix the issue: removed the code dealing with /dev > and /dev/net entries which is used for dlpi operation, do not use functions > and definations in dlpi.h, and make all packet capture works depend on > libpcap? Because the code just use dlpi.h interfaces to get mac address which > is not an important information of iftop. I'm not sure what you mean by "important" here, but getting the hardware (mac) address through libdlpi is pretty simple. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
