This whole argument somehow supposes that "snoop" is special, compared
to numerous other bits of userland software which we also have in ON
which would be nice to exclude.
For example, the commands for things like "diff", "fold", "dc", "cat",
"cal", "calendar", "mail", etc. are all things that are in ON, but which
should only be using standard POSIX interfaces. snoop is basically in
the same category (although it uses DLPI which isn't POSIX specified,
but is part of the SVID if I recall properly.)
It would be awesome to have a separate consolidation for these userland
bits which only consumed standard conforming interfaces, and either only
exported standard or Committed interfaces, or had no other dependents
within ON. That would include not just the command line apps, but
probably also some of the libraries.
SFW is the wrong place for these bits, because SFW is (IIUC) really just
a place for bits that we take from other upstream sources, and generally
have looser requirements for integration. These components, on the
other hand, are supplied directly by the Solaris community and have much
higher bars on change integration, so they need to have a more "native"
upstream consolidation. ON serves that role at present.
The problem with creating a new consolidation for these is mostly that
it means replicating some of the resourcing that we have for ON...
gatekeeping, nightly builds, etc. While I personally believe we could
probably use the same resources we have now, and just put them into a
separate consolidation without a *lot* of cost, its not the case that
such a change comes for free. (IMO, the cost not exceed the benefits --
I think most of the ON build at present is still spent in userland
components which probably almost never change.)
-- Garrett
Sebastien Roy wrote:
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]
_______________________________________________
networking-discuss mailing list
[email protected]
