On Wed, 2009-11-04 at 00:35 +1100, Darren Reed wrote:
> Sebastien Roy wrote:
> > Wireshark and tshark are in SFW, but there is IMO much work to be done
> > to call it a suitable alternative/replacement.  For one, we have a large
> > number of Solaris networking test suites that depend on the snoop CLI
> > and output format (both the snoop file format and the terminal output),
> > and one would need to evaluate how to handle those dependencies.  I have
> > no doubt that similar dependencies exist for user scripts and tools.
> >
> > For that reason, I'm not sure that we'll be able to exclude snoop from a
> > Solaris distribution anytime soon.
> >   
> 
> I agree.
> 
> But a Solaris distribution already includes components from SFW, not 
> just ON.

Yes, I know, I was simply making an argument against ripping out snoop
from the distribution.

> And our test suite already depends on bits from SFW.
> 
> So there is no Rubicon that needs crossing here.
> 
> Why shouldn't snoop become SFW?
> 
> Do we need to have a PSARC case or something to announce the EO-whatever 
> for snoop in order to unbundle it from ON?

The only architecture that this would affect are the potential
consolidation-private interfaces that snoop uses to do its job.  If it
makes extensive use of ON consolidation-private interfaces, then the
person doing this work needs to work out how to untangle that.
Otherwise, moving the clump of source code associated with snoop from
one manure pile to another doesn't really affect the architecture of the
system.

> So the idea I'm proposing is not to "rip snoop out" but to change the 
> location and the home of its source code so that it is no longer 
> considered an integral part of Solaris like it is now. It becomes just 
> another tool for sniffing packets, alongside tcpdump and wireshark, that 
> we bring in from the outside.

I personally don't see the benefit in doing that.  Snoop still needs to
be maintained in previous Solaris versions (at least for high-priority
bug fixes), and the process for integrating such changes involves
integrating changes to the current release under development.  Moving
consolidations increases the cost associated with integrating such fixes
(IMO) without much benefit.

I also think that we have much bigger problems to solve in making sure
that Wireshark and tcpdump can actually replace snoop eventually.  Let's
think about the engineering problems associated with that.  Snoop can
sit in ON just as well as it can sit on sourceforge, I personally don't
see the point in moving it.

-Seb


_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to