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

2005-12-02 Thread Mark Wielaard
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


[Fwd: [cp-patches] [RFC, Concept proposal]: Easing target dependency]

2005-11-30 Thread Guilhem Lavaux

Hi,

As I got no answer on classpath-patches I send this email to this list.

Regards,

Guilhem.
---BeginMessage---

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 stdlib.h
 #include errno.h
+#include string.h
 
-#include jni.h
-#include jcl.h
-
-#include target_native.h
-#ifndef WITHOUT_FILESYSTEM
-#include target_native_file.h
+#if defined(HAVE_UNISTD_H)
+#include unistd.h
 #endif
-#include target_native_math_int.h
 
+#include jni.h
+#include jcl.h
+#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 

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

2005-11-30 Thread Dalibor Topic

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