Bart Smaalders writes: > James Carlson wrote: > > It would make a lot more sense to enhance wireshark ... but it also > > means we have an at best confused approach to our own system > > architecture because we don't have an agreement about what we're > > actually doing. > > > > Well, depriving our customers of the better tool while we go on about > architectural direction doesn't exactly enhance Solaris.
So, in the interest of not "going on about" direction, how about if an ARC member derails this and TCRs it to include snoop obsolescence, and thus a formal change of direction to prohibit new features in snoop. > Some degree > of duplication/competition between tools is useful. I realize that this > can confuse customers somewhat... but introducing this into Nevada seems > to be a useful first step in making a decision. Wireshark/Ethereal has > been around for year. Ethereal's quite a bit older than that. My guess is about 9 years old. > > For instance, does it decode labels for TX? (Last I looked, the > > answer was "no," but that someone at HP was trying to work on a patch > > for it.) > > > > I'm hard pressed to find the list of decoded protocols in the snoop > documentation. Indeed. > When libpcap gets updated, we'll grab a newer copy. We have to do that > whether or not it gets statically or dynamically linked. If someone > else introduces a dynamic libpcap, we can use that easily enough. > Right now w/ only one client it really doesn't add any value. I see. > > In other words, what guarantees do we have (if any) that this software > > will continue to operate as the system changes? > > We'll have to debug any problems that arise. It turns out the kstat > dependencies went away after I used the -zignore option; they were > introduced by libtool (bletch). I'm not sure "debug any problems that arise" counts as architecture ... > > OK. Should we just not support developers, or would those bits be > > more effective as separate packages? > > > > My thoughts are that anyone wishing to add to wireshark in the form of > plugins, etc, will probably grab the source and compile it themselves, > so shipping the development tools is probably not terribly useful. OK, that makes sense. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
