On Sat, Jan 22, 2005 at 10:59:15PM +1030, Brett Lymn wrote:
> On Fri, Jan 21, 2005 at 01:04:00PM -0500, Jan Harkes wrote:
> > 
> > LWP depends on a tiny bit of assembly for each CPU, I don't think anyone
> > has ever written the bit needed for AMD64. In the LWP source tree there
> > is a little 'PORTING' document that contains some notes on what the main
> > obstacles are.
> > 
> 
> Ummmm Jan, I did write that - I submitted a patch for it.  I don't know

Can't find the patch anywhere. I might have deleted it accidentally
while deleting spam from my inbox.

> where it got to but I do still have the code (actually, I put it into the
> NetBSD pkgsrc patches for lwp so I could at least build lwp on my NetBSD
> amd64 machine :)

This weekend I finished some code that I started on a while ago, it uses
the functions provided by ucontext.h (set/get/make/swapcontext). And
since our old servers didn't have ucontext.h it also has a fallback
implementation for these functions which uses sigsetjmp/siglongjmp for
the context switches and sigaltstack or the existing savecontext
assembly to set threads up with their own stack.

It actually seems to work now and it should be more portable.

> > Yeah, once you get LWP running, most of the rest will probably compile
> > but it won't be compatible on the wire with 32-bit architectures.
> > 
> 
> Hmmm... that was not my experience.  I am not sure what is broken
> I get everything built on NetBSD but it looked like RPC was failing to
> connect.  I just put this down to things being broken on a 64 bit platform

It is probably something with the marshalling/unmarshalling, where we
stick a 64-bit value in the outgoing packet buffer, but then only
increment by 4 bytes, so we end up losing half of the original
information and when unpacking we end up copying the overwritten part
back. This should be solvable by forcing RPC2_Integer to be a 32-bit
integer instead of the current (64-bit) long.

Jan