GIVEN:
------
I am working on a Java Network Application that can send/receive raw Ethernet packets.
I bypass the TCP/IP stack and pass them to a DLPI provider. Currently, I am attempting
to use LiS-2.12 (a.k.a LINUX STREAMS: http://www.gcom.com/LiS/) kernel modules
[steams-ldl and streams] to interface the Ethernet card and bypass the TCP/IP stack, and hence
be the DLPI provider/adapter.
I have a few C functions that are tied to my Java app via JNI. Just enough to get messages
sent and received. I can successfully load and init my kernel modules w/o issues.
Taking JNI out of the equation, I was able to run a small C program that uses the putmsg(), and getmsg()
from the libLiS.so lib without problems.
I am using Linux RH6.2 OS and the Blackdown JVM: j2sdk1.3.1 (running native threads).
PROBLEM :
---------
My C functions invoke system-calls: open(), putmsg(), and getmsg() to access the STREAM Head.
My Java App loads my JNI .so lib without Exceptions, but when it gets to the putmsg() system call
in the native code it states the following runtime error:
putmsg(): Function not implemented <---Arghh! what is this?
Here is the JNI library I load in the Java app: libdlpi.so
>ldd libdlpi.so
libLiS.so => /usr/lib/libLiS.so (0x4000d000)
libc.so.6 => /lib/libc.so.6 (0x4000f000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
I am linked against libLiS.so, so I should be able to access the STREAM head with
putmsg() and getmsg()- right? Well, it does not.
So I started looking in the shared libs:
> nm libdlpi.so | grep getmsg
U getmsg
> nm libLiS.so | grep getmsg
0000060c T getmsg
> nm libc.so.6 | grep getmsg
000f4860 ? __evoke_link_warning_getmsg
000dbe1c T getmsg
Well I suspect it is finding the implementation of putmsg() in the libc.so.6,
and this is where the implementation error is coming from.
ALREADY ATTEMPTED:
--------------------
1.) I have checked the LD_LIBRARY_PATH in '.java_wrapper' and put my libLiS.so directory
in the front of the path.
2.) I pass my Java app a JVM property:'-Djava.library.path=<dir where libs are>' in
a startup script. Of course, I put my libs in front.
3.) I tried 'LD_PRELOAD=./libdlpi.so' but it hangs the java app.
I can compile and link my shared lib (libdlpi.so) w/o any errors with this Makefile:
<<Makefile>>
LIS_HDRS=/usr/src/LiS/include
JAVA_HDRS=/home/lab/j2sdk1.3.1/include
JAVA_LINUX_HDRS=/home/lab/j2sdk1.3.1/include/linux
INCLUDES=-I$(LIS_HDRS) -I$(JAVA_HDRS) -I$(JAVA_LINUX_HDRS)
FLAGS= -DLINUX -D_REENTRANT -ggdb -fPIC
dlpi: dlpi.c
gcc $(FLAGS) $(INCLUDES) -lLiS dlpi.c -shared -o libdlpi.so
<<END Makefile>>
All I need is for my C implementation to communicate with the STREAM head (kernel modules)
via putmsg() and getmsg() functions from libLiS.so;
I am at my wits end, and would appreciate any suggestions, or insight.
(I am still learning all this stuff.)
QUESTIONS
---------
Q1.) Why is the JVM eclipsing my getmsg() and putmsg() syscalls with this from libc?
Q2.) Does the following restriction apply to the linux 1.3.1 (native threads)?
The SCO java implementation states this is a restriction due to 'green threads',
but I am not using green threads, and Blackdown has not made such a statement about
the Linux JVM (to my knowledge).
---------------------------------------------------------------------------------
FROM: http://java.sun.com/docs/books/tutorial/native1.1/implementing/invo.html
The user-level Java thread implementation on Solaris requires the
Java VM to redirect certain Solaris system calls. The set of
redirected system calls currently includes read, readv, write,
writev, getmsg, putmsg, poll, open, close, pipe, fcntl, dup,
create, accept, recv, send, and so on. This may cause undesirable
effects on a hosting native application that also depends on these
system calls.
---------------------------------------------------------------------------------
will quan
