classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fwd: [cp-patches] [RFC, Concept proposal]: Easing "target" dependen


From: Dalibor Topic
Subject: Re: [Fwd: [cp-patches] [RFC, Concept proposal]: Easing "target" dependency]
Date: Wed, 30 Nov 2005 20:55:55 +0100
User-agent: Mozilla Thunderbird 1.0.7 (X11/20051013)

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 <address@hidden>
Date:
Sat, 26 Nov 2005 14:50:03 +0100
To:
address@hidden

To:
address@hidden


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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]