[ipv6] Regarding 8220673: Add test library support for determining platform IP support

[Arthur Eubanks]

While looking through some of the tests, I noticed that there is
jdk.test.lib.NetworkConfiguration which has methods like "isIPv6Available".
It seems much more comprehensive than what is in the proposed IPSupport.
Although the methods are not static and require a `NetworkConfiguration nc
= NetworkConfiguration.probe()`.

Regarding trusting the IPSupport, I have checked to make sure that it's
reasonable. It correctly throws a jtreg.SkippedException when
preferIPv4Stack is true and IPv4 is not available, and leaves the other
cases alone. This was tested with an LD_PRELOAD that returns an error on
`socket()`, `setsockopt()`, and `getifaddrs()` on IPv4 addresses. Under a
typical dual stack configuration it doesn't throw anything. This was a good
idea, thanks Daniel.

On Thu, Apr 11, 2019 at 11:45 AM Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Hi,
>
> If you need different @requires for different runs, there is a jtreg
> feature to define separate tests using separate comment blocks.
>
> /*...
>   *@requires x
>   *@run ...
>   */
>
> /*
>   * @requires !x
>   * @run ...
>   */
>
> $.02, Roger
>
>
> On 04/11/2019 12:01 PM, Chris Hegarty wrote:
> > Arthur, Daniel,
> >
> >> On 10 Apr 2019, at 21:39, Arthur Eubanks <aeubanks at google.com
> >> <mailto:aeubanks at google.com>> wrote:
> >>
> >> Here's a prototype webrev to see if the approach is okay with you. If
> >> it looks good, I'll continue with the remaining tests I can find.
> >> (should I start a new thread for the webrev?)
> >>
> >> http://cr.openjdk.java.net/~aeubanks/8220673/webrev.00
> >> <http://cr.openjdk.java.net/%7Eaeubanks/8220673/webrev.00>
> >
> > This is not too bad. Given the typical usage, one `@run` followed by a
> > second `@run + system property`, then we kinda cannot easily use an
> > `@requires`. Also, it would be good to dump/print the IP configuration,
> > as determined by IPSupport, if the test will not be run. This will be
> > useful when digging into test output jtr files.
> >
> > An alternative, rather than simple returning ( when the configuration
> > does not support the test ) maybe throw jtreg.SkippedException [1], to
> > indicate that the test has been skipped (rather than run successfully).
> > An example of this is LevelTransitionTest [2].
> >
> > That said, I would still like to experiment a little with @requires for
> > the cases where there is a single @run tag.
> >
> >
> >> On 11 Apr 2019, at 14:05, Daniel Fuchs <daniel.fuchs at oracle.com
> >> <mailto:daniel.fuchs at oracle.com>> wrote:
> >> ...
> >> We're putting a lot of trust in the implementation of this
> >> IPSupport utility.
> >
> > Yes, this is a good point. What’s nice about this is that there is just
> > one body of code that provides the functionality ( and it is all in
> > Java, not native). I'm interested to see how this performs in Arthur's
> > experiments, and I need to do a little more testing myself. It is
> > important that a test leaves enough breadcrumbs behind if it decides
> > that it will not run.
> >
> > -Chris
> >
> > [1]
> >
> https://openjdk.java.net/jtreg/faq.html#what-if-a-test-does-not-apply-in-a-given-situation
> > [2]
> >
> https://hg.openjdk.java.net/jdk/jdk/file/tip/test/hotspot/jtreg/compiler/tiered/LevelTransitionTest.java
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190415/00a4129e/attachment.html>