Re: Kaffe for BeOS R4 -- progress made

Date view Thread view Subject view Author view

From: Godmar Back (gback@marker.cs.utah.edu)
Date: Sun Jan 03 1999 - 23:49:54 EST


 Hi Alan,

>
> I've a question about how to provide stubs for things like "getsockopt"
> (which BeOS doesn't support yet). Putting in the stub into
> unix-jthreads/internal.c (I think that's wher I put it) was nasty; I think
> I ought to have made a separate file somewhere in the libraries/clib
> hierarchy...

You do have the option of creating a file md.c in config/i386/beos/md.c

>
> They can at least be represented as integers; however , read() and write()
> don't work for sockets -- one must use send*() and recv*() instead :(
>

Kaffe uses KSOCKREAD and KSOCKWRITE, which correspond to different entries
in the jsyscall table.

It appears that BeOS is not sufficiently UNIX-compatible to warrant the
use of the syscall table in systems/unix-jthreads/internal.c.
I recommend you create a systems/beos-jthreads/ directory; this allows you
to define a Kaffe_SystemCallInterface table that does not use the same
functions for KSOCKREAD and KREAD. This would also fit in your plans of
developing a port to BeOS native threads; so call it maybe
systems/beos-native/ instead.

One thing I would like you to keep in mind, however, is that I don't like
the current threading interface. That is, I'm working on convincing Tim
and the other core team members to adapt an interface more similar to
the one defined by jthread.h. In fact, if I find the time, I might just
do it. The plan is then to move most of
systems/unix-jthread/internal.c into the kaffevm/ directory.

Having a `BeOS jthreads' port would be great. (I already have a pthreads
port that'll be included into CVS shortly) Ideally, you wouldn't have to make
changes to internal.c (except, of course, for the syscall table --- which
we would put in a separate file then; say internalCalls.c). Instead,
you would implement the `jthread_' functions upon which internal.c relies
using BeOS_thread functions. Like I said, I've already done that for
pthreads. The jthreads interface will then only be a thin veneer.
Does that make sense?

Note that this veneer should be thin. It could be as thin as defining
#define jthread_current() beos_thread_current()
This way, the overhead should be small. If you're interested, you can
look at the pthread implementation at
ftp://flux.cs.utah.edu/flux/oskit/kaffe/kaffe.tar.gz
This might give you a good starting point for a native port.

If it's okay with you, I'll hold off with including fixes until exceptions
etc. work.

     - Godmar


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:28 EDT