Taking (for no particular reason) TSCOG's statement in the SCO v. IBM hearing on April 14, 2006, that:

"Item number 53 is at tab 20, and, again, I'm going to be general because of the confidentiality. But this is a method and concept which deals with improving locking, and if you turn to the first page after our header slide, you see the actual disclosure. It identifies who made the disclosure, an IBM employee, Mr. Wright; the nature of that disclosure, which is not amorphous. It's very specific. It refers to the e-mails and quotes them, where those were actually made to a Daniel Phillips, who was a Linux developer, and it makes specific references that they are getting this from Dynix/ptx."

let's start chasing rabbits down holes and see what we find.

Some groundwork had already been done at http://www.groklaw.net/article.php?story=20060508230734757:

ITEM 53
-------
page 53, line 2 thru page 54, line 16 discusses item 53 from SCO's list of material allegedly misused by IBM. It discusses an email from Tim Wright which can be found here:

http://www.ussg.iu.edu/hypermail/linux/kernel/0012.2/0497.html
Subject: Re: [RFC] Semaphores used for daemon wakeup
From: Tim Wright
Date: Tue Dec 19 2000 - 11:07:59 EST

Since I prefer working directly from the LKML archives, let's find this post and see what (if anything) was going on...

Tim Wright was not the original poster in this thread, and in fact made only three posts out of eight total posts made to the thread "[RFC] Semaphores used for daemon wakeup" started by Daniel Phillips, see http://lkml.org/lkml/2000/12/17/94 dated Sun, 17 Dec 2000 13:06:10 +0100

Daniel Phillips starts out with a Request For Comments:

"This patch illustrates an alternative approach to waking and waiting on daemons using semaphores instead of direct operations on wait queues. The idea of using semaphores to regulate the cycling of a daemon was suggested to me by Arjan Vos."

Phillips immediately corrects himself:

"< The idea of using semaphores to regulate the cycling of a daemon was
< suggested to me by Arjan Vos.
Actually, his name is Arjan van de Ven - sorry Arjan :-o
Thanks also to Phillip Rumpf for auditing this patch for cross-platform correctness."

So Phillips is working on (I'm paraphrasing, here..) kernel task scheduling with suggestions and review from two other parties.

A reply is received from Nigel Gamble dated Mon, 18 Dec 2000 16:14:56 -0800 (PST) -- so we're already into the next day:

"This is much better, especially from a maintainability point of view.
It is also the method that a lot of operating systems already use."

At Mon, 18 Dec 2000 19:34:05 -0800, three hours after Nigel Gamble's statement, Tim Wright replies:

"Well, I have to confess I'm rather fond of this method, but that could have something to do with it being how we did it in DYNIX/ptx (Sequent).
It certainly works, and I find it very clear, but of course I'm biased :-)"

OK: so Phillips publicly requests comments on the LKML for his approach after receiving prior assistance from two other people, and a day later Tim Wright says he likes it because that's how we did it in DYNIX/ptx (Sequent).

Did Phillips receive information from Wright about how to craft his approach, or did Wright merely encourage Phillips after the fact?

Which came first, the horse or the cart?

Daniel Phillips replies:

"I'm curious, is my method of avoiding the deadlock race the same as yours? My solution is to keep a count of tasks that 'intend' to take the down():

        atomic_inc(&bdflush_waiters);
        up(&bdflush_request);
        down(&bdflush_waiter);

so that bdflush will issue the correct number of up's even if the waiter has not yet gone to sleep. IOW, is your approach in DYNIX the same only in spirit, or in detail?"

Catch that? In his reply Phillips asks Wright if the two approaches are the same. And, he goes beyond that and asks if the two approaches are the same only in spirit, or in detail.

Does that sound like Daniel Phillips has received prior instruction from Tim Wright as to the methods and concepts used to solve this issue in Dynix/ptx?

Hell no.

It doesn't sound anything like that at all.

In fact, Tim Wright goes on in reply:

"OK, this is not how we generally would achieve the goal, although the approach looks valid. We have a number of primitives available that are not currently used in Linux (unless I'm losing my eyesight :-)"

What does that sound like to you? To me, it sounds like "Yeah, that's not quite how we did it, but it looks like it would work..."

And Phillips says:

"Yes, I see. There are a lot of similarities to the situation I described. The main difference between this situation and bdflush is that dmabuf_free isn't really waiting on dmabuf_alloc to fullfill a condition (other than to get out of its exclusion region) while bdflush can have n waiters.

If I could have a new primitive for this job it would be up_down(sem1, sem2), atomic with respect to a sleeper on sem1. And please give me an up_all for good measure..."

In closing, let's review TSCOG's statement:

"It identifies who made the disclosure, an IBM employee, Mr. Wright; the nature of that disclosure, which is not amorphous. It's very specific. It refers to the e-mails and quotes them, where those were actually made to a Daniel Phillips, who was a Linux developer, and it makes specific references that they are getting this from Dynix/ptx."

Is that what happened in this LKML thread?

Nope.

Another TSCOG lie, plain and simple.

i_s_g

< EOM >