(Illustration by Gaich Muramatsu)
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. JanReceived on 2005-01-24 16:19:14