[Fwd: [cp-patches] [RFC, Concept proposal]: Easing "target" dependency]
Hi,
As I got no answer on classpath-patches I send this email to this list.
Regards,
Guilhem.
--- Begin Message ---
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.
Cheers,
Guilhem.
Index: native/jni/java-nio/Makefile.am
===
RCS file: /cvsroot/classpath/classpath/native/jni/java-nio/Makefile.am,v
retrieving revision 1.19
diff -u -r1.19 Makefile.am
--- native/jni/java-nio/Makefile.am 23 Oct 2005 16:59:08 - 1.19
+++ native/jni/java-nio/Makefile.am 26 Nov 2005 13:48:57 -
@@ -6,7 +6,9 @@
gnu_java_nio_charset_iconv_IconvDecoder.c \
gnu_java_nio_charset_iconv_IconvEncoder.c \
java_nio_MappedByteBufferImpl.c \
- java_nio_VMDirectByteBuffer.c
+ java_nio_VMDirectByteBuffer.c \
+ javafileio.c \
+ javafileio.h
libjavanio_la_LIBADD = $(top_builddir)/native/jni/classpath/jcl.lo \
$(LTLIBICONV)
Index: native/jni/java-nio/gnu_java_nio_channels_FileChannelImpl.c
===
RCS file:
/cvsroot/classpath/classpath/native/jni/java-nio/gnu_java_nio_channels_FileChannelImpl.c,v
retrieving revision 1.27
diff -u -r1.27 gnu_java_nio_channels_FileChannelImpl.c
--- native/jni/java-nio/gnu_java_nio_channels_FileChannelImpl.c 3 Aug 2005
13:12:59 - 1.27
+++ native/jni/java-nio/gnu_java_nio_channels_FileChannelImpl.c 26 Nov 2005
13:48:57 -
@@ -40,16 +40,15 @@
#include
#include
+#include
-#include
-#include
-
-#include "target_native.h"
-#ifndef WITHOUT_FILESYSTEM
-#include "target_native_file.h"
+#if defined(HAVE_UNISTD_H)
+#include
#endif
-#include "target_native_math_int.h"
+#include
+#include
+#include "javafileio.h"
#include "gnu_java_nio_channels_FileChannelImpl.h"
#ifdef HAVE_FCNTL_H
@@ -80,12 +79,12 @@
#define IO_EXCEPTION "java/io/IOException"
/* FIXME: This can't be right. Need converter macros. */
-#define CONVERT_JLONG_TO_INT(x) TARGET_NATIVE_MATH_INT_INT64_TO_INT32(x)
-#define CONVERT_INT_TO_JLONG(x) TARGET_NATIVE_MATH_INT_INT32_TO_INT64(x)
+#define CONVERT_JLONG_TO_INT(x) ((int)(x))
+#define CONVERT_INT_TO_JLONG(x) ((jlong)(x))
/* FIXME: This can't be right. Need converter macros. */
-#define CONVERT_JLONG_TO_OFF_T(x) TARGET_NATIVE_MATH_INT_INT64_TO_INT32(x)
-#define CONVERT_OFF_T_TO_JLONG(x) TARGET_NATIVE_MATH_INT_INT32_TO_INT64(x)
+#define CONVERT_JLONG_TO_OFF_T(x) ((off_t)(x))
+#define CONVERT_OFF_T_TO_JLONG(x) ((jlong)(x))
/* FIXME: This can't be right. Need converter macros */
#define CONVERT_JINT_TO_INT(x) ((int)(x & 0x))
@@ -162,53 +161,54 @@
&& (mode & FILECHANNELIMPL_FILEOPEN_FLAG_WRITE))
{
/* read/write */
- flags =
- TARGET_NATIVE_FILE_FILEFLAG_CREATE |
- TARGET_NATIVE_FILE_FILEFLAG_READWRITE;
- permissions = TARGET_NATIVE_FILE_FILEPERMISSION_NORMAL;
+ flags = O_CREAT | O_RDWR;
+ permissions = FILEPERMISSION_NORMAL;
}
else if ((mode & FILECHANNELIMPL_FILEOPEN_FLAG_READ))
{
/* read */
- flags = TARGET_NATIVE_FILE_FILEFLAG_READ;
- permissions = TARGET_NATIVE_FILE_FILEPERMISSION_NORMAL;
+ flags = O_RDONLY;
+ permissions = FILEPERMISSION_NORMAL;
}
else
{
/* write */
- flags =
- TARGET_NATIVE_FILE_FILEFLAG_CREATE |
- TARGET_NATIVE_FILE_FILEFLAG_WRITE;
+ flags = O_CREAT | O_WRONLY;
if ((mode & FILECHANNELIMPL_FILEOPEN_FLAG_APPEND))
{
- flags |= TARGET_NATIVE_FILE_FILEFLAG_APPEND;
+ flags |= O_APPEND;
}
else
{
- flags |= TARGET_NATIVE_FILE_FILEFLAG_TRUNCATE;
+ flags |= O_TRUNC;
}
- permissions = TARGET_NATIVE_FILE_FILEPERMISSION_NORMAL;
+ permissions = FILEPERMISSION_NORMAL;
}
if ((mode & FILECHANNELIMPL_FILEOPEN_FLAG_SYNC))
{
- flags |= TARGET_NATIVE_FILE_FILEFLAG
Re: [Fwd: [cp-patches] [RFC, Concept proposal]: Easing "target" dependency]
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
Re: [Fwd: [cp-patches] [RFC, Concept proposal]: Easing "target" dependency]
Hi Guilhem, > On Wed, 2005-11-30 at 20:31 +0100, Guilhem Lavaux wrote: > > 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. Everything that replaces the macros with real functions has my vote. I have had to debug my way through the macros and it was a pain. > > 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). My preference would be for one cp_io.c, cp_net.c file per core package. > > 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. This makes the source much more readable for me so I am happy. The only thing I would like to see changed is to explicitly start all functions with cp_ ,to make clear that these symbols are part of the GNU Classpath library (we have the same naming scheme with the gtk+ awt peer native implementation). Thanks, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [Fwd: [cp-patches] [RFC, Concept proposal]: Easing "target" dependency]
Hi Mark, Mark Wielaard wrote: Hi Guilhem, On Wed, 2005-11-30 at 20:31 +0100, Guilhem Lavaux wrote: 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. Everything that replaces the macros with real functions has my vote. I have had to debug my way through the macros and it was a pain. 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). My preference would be for one cp_io.c, cp_net.c file per core package. 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. This makes the source much more readable for me so I am happy. The only thing I would like to see changed is to explicitly start all functions with cp_ ,to make clear that these symbols are part of the GNU Classpath library (we have the same naming scheme with the gtk+ awt peer native implementation). Ok. No problem with that. I would rather use classpath_ completely though to avoid namespace confusion. Thanks, Guilhem. Thanks, Mark ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
