Guilhem Lavaux wrote:
Hi,
As I got no answer on classpath-patches I send this email to this list.
Regards,
Guilhem.
------------------------------------------------------------------------
Subject:
[cp-patches] [RFC,Concept proposal]: Easing "target" dependency
From:
Guilhem Lavaux <[EMAIL PROTECTED]>
Date:
Sat, 26 Nov 2005 14:50:03 +0100
To:
classpath-patches@gnu.org
To:
classpath-patches@gnu.org
Hi,
I would like to propose a code split to split the java interface from
accessing syscalls in File IO (and generally for all native IO). Some VM
may want (like us in kaffe) to change the way syscalls are called
without touching the java interface logic. So I am proposing to keep the
basic skeleton of the target layer but put the real code not in macro
but in real C functions. That way we will be able to add autoconf macros
without bothering the java interface and if some persons still want to
use the TARGET layer it is possible by simply using the macro inside the
C functions.
So here is a patch which shows what I want to do. An idealistic
situation would be to put all these functions which are using syscalls
into a libjavasyscalls which will be implemented by VM writers (and of
course we will propose a default implementation).
This is not the definite patch. So don't complain about missing
ChangeLog and so on ... I ask whether people agree on using that concept.
I love the idea. It should work well, and help make the GNU Classpath
native code clearer and more hackable in those yucky native parts.
cheers,
dalibor topic
_______________________________________________
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
