On 01/16/09 00:54, James Carlson wrote: > 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. > OK. The original code have been exacted at /net/flowerpath.prc/export/home/iftop/b/iftop-0.17/ The changed code directory: /net/flowerpath.prc/export/home/iftop/a/iftop-0.17/ And here is the patch(diff -ur output): /net/flowerpath.prc/export/home/iftop/to.patch
Thank you for helping me to look into the code. - Xiang > 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. > -- Best Regards, Xiang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20090116/d74d23ba/attachment.html>
