Chris, Yes, I'm asking more general question - it's why I address it to you but Frank.
IMHO, logic cleanup would take almost the same time as just reformatting macros (in all cases testing is required) and create almost the same disturbance for people porting openjdk to other platforms. So (on my opinion) it's better to do it once. Also do we really supports linux 2.2 kernel in jdk8? I think not, and all related macros should be removed within a scope of any bug touching the file. -Dmitry On 2012-08-16 16:23, Chris Hegarty wrote: > You already know this, but to be clear, Frank's changes are simply > changing the definitions so that platforms like AIX will use the same > implementation as Solaris, Mac, etc. There will be no behavior changes > from this. You're just asking general questions, right? > > On 16/08/2012 12:25, Dmitry Samersoff wrote: >> Chris, >> >> Sorry for being later at the party. >> >> 1. >> >> Could you explain why you are calling both >> >> mcast_set_if_by_addr_v4 >> mcast_set_if_by_addr_v6 >> >> for Linux >> >> and only >> >> mcast_set_if_by_addr_v6 >> >> for other OS-es. > > There is a lot of history here and many bugs over the years. I'll try to > summarize. > > It was found that the dual stack on Linux requires that both the IPv4 > and IPv6 socket options (IP_MULTICAST_IF & IPV6_MULTICAST_IF) are > required to set the outgoing interface for sending multicast packets. > Similarly for other sockets options. > > This was introduced under CR 4742177 [1]. From 4742177: > "So with regard to ipv4 and ipv6 socket option, Solaris behaves this > way :- > - ipv4 options can be set for ipv4 socket fd, and ipv6 options for > ipv6 socket fd. Otherwise, an error will occur. > - effective options are those belong to the same family of socket > fd. > > Meanwhile, Linux behaves this way :- > - both ipv4 options and ipv6 options can be set for a socket fd. > - effective options are those belong to the same family of > destination address." > >> 2. If it's really necessary >> did you consider of writing special variant of mcast_set_if_by_addr_v6 >> combined both functionality for linux to reduce number of JNI >> (FindClass) calls and macros inside code ? > > Unfortunately, this behavior is necessary. I agree, the code is not all > that pretty, and there is a lot that could be done to clean it up, but I > would like to keep this issue confined to Franks's particular problem. > > -Chris. > > [1] http://bugs.sun.com/view_bug.do?bug_id=4742177 > >> >> >> -Dmitry >> >> >> On 2012-08-16 13:21, Frank Ding wrote: >>> On 8/14/2012 10:42 PM, Chris Hegarty wrote: >>>> On 14/08/12 13:11, Alan Bateman wrote: >>>>> On 14/08/2012 04:11, Frank Ding wrote: >>>>>> On 8/7/2012 1:46 PM, Frank Ding wrote: >>>>>>> : >>>>>>> >>>>>>> Could anybody take a look at my patch below and make comment? >>>>>>> http://cr.openjdk.java.net/~youdwei/ojdk-533/webrev.00/ >>>>>>> >>>>>>> Thanks& Best regards, >>>>>>> Frank >>>>>> >>>>>> Hi all, >>>>>> Is there anybody who is interested in the patch and who can take a >>>>>> look and comment? >>>>> It looks okay to me but I don't have time at the moment to sponsor it. >>>>> Can you confirm that you've run the tests with this change? >>>> >>>> I filed 7191275: "Cleanup OS specific vinblocks in >>>> PlainDatagramSocketImpl.c to support more unix-like platforms",for >>>> this issue. >>>> >>>> I can sponsor this patch and help get it in. Can answer Alan's >>>> question about testing? And confirm that it builds on all platforms? >>>> >>>> Thanks, >>>> -Chris. >>>> >>>>> >>>>> -Alan >>>> >>> Hi Chris and Alan, >>> Thank you for taking time to help this issue. I have built using >>> latest openjdk 8 repo on Windows 64 and Linux 32/64. Since it's a macro >>> change in path "src/solaris", I only did jtreg tests for Linux 32 and 64 >>> build. The jtreg tests I ran are restricted to package "java/net". >>> Please let me know if you need me to do more tests or on more platforms >>> (such as Solaris). >>> >>> Best regards, >>> Frank >>> >> >> -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ...
