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 t.p.ellison@gmail.com designates
 66.249.82.202 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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=BaxsullfbsfNnTYfHwrUhzW8EjJtbEP03b/E/+Uc2VA8BIl3ouE4aZHCqOc2VtSRfu+uRTuWjqsphXlDlWJJurRPi7h0/60DnkbHSG9oo3BPOWS5yAdrLuWIH198xP3O2Y7FieYIbxkygZS3EQgkuPvLaTC4hUk3MKXSQgTnIpU=
Message-ID: <5899fca70607250823w6b2af13cs3324f53adcfb93f3@mail.gmail.com>
Date: Tue, 25 Jul 2006 16:23:01 +0100
From: "Tim Ellison" <t.p.ellison@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: portlib functionality
In-Reply-To: <9605648e0607250534n61722dfese6c96d8f827713d0@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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>
	 <9605648e0607250534n61722dfese6c96d8f827713d0@mail.gmail.com>

(Thanks for bringing this onto the list Paulex)

On 25/07/06, Marina Goldburt <marina.v.goldburt@gmail.com> wrote:
> 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.

We should discuss what functions you see as candidates for extension
to the portlibrary.

> The second was that this mechanism needs vm recompilation.

If you honour the existing table layout then you don't need to break
compatibility.  In addition, VMs are not required to use the class
library portlib if they choose not to.

> But it's ok since
> Harmony has its own vm and nobody uses j9 vm binaries.

This is a joke right?  There are three VMs in various states of
development at Harmony, and people are also using the IBM VME.

Regards,
Tim


> 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

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org