[Top] [All Lists]

Re: thread-ready ABIs

Subject: Re: thread-ready ABIs
From: Machida Hiroyuki <>
Date: Sun, 20 Jan 2002 22:16:07 +0900
In-reply-to: <002c01c1a1a9$b9f0de40$0deca8c0@Ulysses>
References: <> <> <002c01c1a1a9$b9f0de40$0deca8c0@Ulysses>

From: "Kevin D. Kissell" <>
Subject: Re: thread-ready ABIs
Date: Sun, 20 Jan 2002 12:58:00 +0100

> I don't read Japanese, but I've worked on similar
> methods for semaphores using k1, so I can guess
> roughly what you've done.   We'll have to be very
> careful if we want to have both a thread-register
> extended ABI *and* this approach to semaphores.
> The TLB miss handler must inevitably destroy one
> or the other of k0/k1, though it can avoid destroying
> both.  Thus the merge of thread-register+semaphore
> must not require that both be preserved on an
> arbitrary memory reference.  That may or may not
> be possible, so it would be good if you guys at
> Sony could post your code ASAP so we can see
> what can and cannot be merged.

We released source codes to the public with PS2 Linux (beta
version) DISC. But I think you can't get the DISC in outside of
japan. Patches included in those SRPMs are not separeted by
function. That meanes single big patche includes r5900 porting
codes, r5900 specific devices drivers and other enhancements. 
I can put kernel and glibc SRPMs in that DISC to you ftp site, if
you really want to get SRPMs with such a dirty patch.
Please send me your ftp site and how to put, if you want to SRPMs.

I'll write short descriptions about what our test-and-set does,
and try to make a separate patch for the method, anyway.

> This situation also behooves us to verify that
> k0/k1 are really and truly the only candidates
> for a thread register in MIPS.  I haven't been

Sorry, I don't read libc-hackers's archives yet...

Hiroyuki Machida
Sony Corp.

<Prev in Thread] Current Thread [Next in Thread>