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 <[EMAIL PROTECTED]> 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* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> 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* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> > 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
