Chris, You probably need to modify
jdk/make/mapfiles/libnet/mapfile-vers -Dmitry On 2014-02-24 18:19, Chris Hegarty wrote: > On 24/02/14 14:12, Michael McMahon wrote: >> On 24/02/14 14:09, Chris Hegarty wrote: >>> On 24/02/14 10:42, Michael McMahon wrote: >>>> On 23/02/14 08:55, Chris Hegarty wrote: >>>>> On 22 Feb 2014, at 17:23, Dmitry Samersoff >>>>> <dmitry.samers...@oracle.com> wrote: >>>>> >>>>>> Chris, >>>>>> >>>>>> Didn't look to windows part. Unix part looks good for me. See also >>>>>> below. >>>>>> >>>>>> I'm a bit concerned because of mixing NET_* abstractions and direct >>>>>> call >>>>>> to OS functions. It might be better to create NET_socket etc. >>>>> Me too. It is already a mess. System calls should be used directly, >>>>> unless there is a reason not to do so. >>>>> >>>>>> We use NET_GetSockOpt/NET_SetSockOpt in one places and plain os >>>>>> functions in other ones it have to be unified. >>>>> If there is no reason to call the NET_ variant, then the system call >>>>> should be used. >>>> >>>> Seems like the big #ifdef in net_util_md.h on this is more or less >>>> redundant now >>>> since the #define of NET_xxx to JVM_xxx was its only purpose. >>> >>> The only difference between these now is that the bsd/linux variant >>> are defined in a separate file ( extern ), bsd_close/linux_close. I'm >>> not sure, but I think the use of extern is still required here. >>> >> >> I think extern would be okay in the other case though. All C functions >> are extern unless >> declared static afaik. > > Thanks. I'll include extern, and remove the other definitions. > > -Chris. > >> >>>> I wonder would it also be useful to expand the comment just above those >>>> definitions >>>> that currently just relates to AIX and say which other operating >>>> systems >>>> it applies to >>>> and if we could identify which system calls it affects, and which mean >>>> the NET_xx >>>> functions must be used. Or maybe this is going beyond what you >>>> wanted to >>>> do here? >>> >>> Beyond ;-) There is still a lot of cleanup that I want to make to this >>> code, but I'd like to do it incrementally, starting with breaking the >>> dependency on the VM interface. This makes it easier, certainly from a >>> review point of view. >>> >>> -Chris. >>> >>>> >>>> Michael >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.
