Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of marina.v.goldburt@gmail.com
 designates 64.233.182.184 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
        b=BebYz9P7AXykeogGsMCt4rK2e02yHsR3HcFrPntG5NRiIAb9Fn6aH9jOxVhdZYkmHUHchub0XHjUIxM40KtaMk4BwOJj2L9AsI2kTUwL8v1nkBbxAB7vw8IWpBBukPyLIwPs8HObFq3M2PYI08lw6BnAyXmH2MCOI5Rf3weffBo=
Message-ID: <9605648e0607250534n61722dfese6c96d8f827713d0@mail.gmail.com>
Date: Tue, 25 Jul 2006 16:34:19 +0400
From: "Marina Goldburt" <marina.v.goldburt@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: portlib functionality
Cc: paulex.yang@gmail.com
In-Reply-To: <44C608BA.2050505@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_12630_14178903.1153830859520"
References: <9605648e0606190510g3333137fi5d0e6eab25bfba7e@mail.gmail.com>
	 <44AD3A0E.6070009@gmail.com> <44ADCFF7.7040603@gmail.com>
	 <9605648e0607240437t63a52e48m10b1e43b055d8881@mail.gmail.com>
	 <44C5EF7D.1000501@gmail.com>
	 <9605648e0607250406p5cf15da1o93b27fa60320a65d@mail.gmail.com>
	 <44C608BA.2050505@gmail.com>

------=_Part_12630_14178903.1153830859520
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Yes, this is the straightforward mechanism.

The only objection is that adding all the missed functions to the
HyPortLibrary structure leads to its significant growing.

The second was that this mechanism needs vm recompilation. But it's ok since
Harmony has its own vm and nobody uses j9 vm binaries.

Marina.

On 7/25/06, Paulex Yang <paulex.yang@gmail.com> wrote:
>
> Marina,
>
> Actually... I didn't catch up here about "how the portlib can be
> extended", if you mean what API should look like about the mmap portable
> version, yes, I meant this; or if you mean the portlib's mechanism to
> extension, I thought it is straightforward, so please correct me if I
> make mistakes or miss sth., I thought it needs three steps:
>
> 1. Modify hyport.h to add the function prototyp, add the new function
> prototypes to function table(Struct HyPortLibrary), add a macro to
> access the new item(like #define hystr_printf
> privatePortLibrary->str_printf)
> 2. add the function declaration in portpriv.h, and add the reference to
> function table instance(MasterPortLibraryTable)
> 3. implement the function for every platform, and modify makefile if
> necessary
>
> BTW, would you mind if I forward this to the mailing list? I think
> probably more people will have interest on this topic:).
>
> Marina Goldburt wrote:
> > Paulex,
> >
> > As I understand, the proposal'll be about how the portlib can be
> extended?
> > While you're preparing the proposal, I'll look through the classlib
> > code and  try to prepare the list of the possible portlib extensions.
> >
> > Thanks, Marina.
> >
> >
> > On 7/25/06, *Paulex Yang* <paulex.yang@gmail.com
> > <mailto:paulex.yang@gmail.com>> wrote:
> >
> >     Marina,
> >
> >     I've completed the implementation of mmap, and they are good
> >     candidates
> >     to be refactored as extension of portlib. I'm a little guilty that
> it
> >     appears in slow paces...I'll post a proposal about this soon.
> >
> >     And I believe there are other candidates in NIO and other
> >     modules(FileLock, ICMP ECHO REQUEST, etc), your (and anyone others')
> >     ideas and suggestions are welcome:).
> >
> >     Marina Goldburt wrote:
> >     > Hi, Paulex,
> >     >
> >     > On 7/7/06, *Paulex Yang* <paulex.yang@gmail.com
> >     <mailto:paulex.yang@gmail.com>
> >     > <mailto:paulex.yang@gmail.com <mailto:paulex.yang@gmail.com>>>
> >     wrote:
> >     >
> >     >     Yes, I'm working on the FileChannel completion, and my
> >     thought is to
> >     >     write platform dependent codes for mmap at first(I thought it
> is
> >     >     easier
> >     >     to be accepted, so that things can be moved forward), then
> >     propose a
> >     >     mmap related extension to portlib, and if it is accepted,
> >     refactor the
> >     >     codes. The current portlib's mmap API cannot meet the
> >     requirement
> >     >     of nio
> >     >     in several ways:
> >     >     1. cannot map file in modes other than Copy-On-Write
> >     >     2. cannot map part of file
> >     >     3. cannot pick up the opened file descriptor as parameter
> >     >
> >     >     Will look at the file locking later...And I'm sure there are
> >     other
> >     >     things worthing evaluation to be portlib extension.
> >     >
> >     >
> >     > What is the current state of your development?
> >     > As I see, you didn't extend portlib functionality yet.
> >     > How are you going to do it?
> >     >
> >     > As everybody agrees that moving all platform-dependent code of the
> >     > luni module to the portlib is the correct idea,
> >     > let's discuss the way the portlib can be extended.
> >     >
> >     > Marina.
> >     >
> >
> >
> >     --
> >     Paulex Yang
> >     China Software Development Lab
> >     IBM
> >
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>

------=_Part_12630_14178903.1153830859520--