Re: [TUHS] First Unix-like OSes not derived from AT&T code?

[Clem Cole <clemc@ccc.com>]

[-- Attachment #1: Type: text/plain, Size: 5065 bytes --]

On Mon, May 2, 2022 at 10:46 AM tytso <tytso@mit.edu> wrote:

> So it appears that it was not a
> matter of "the upstream Linux kernel team.... [being] willing to take
> the VPROC changes", it was more like no one asked, or prepared patches
> that could be considered by usptream.
>
FWIW:  I know that at least 3 people on the OpenSSI team were telling me
they were told to go away.   I do not know the details of the interchange,
but doing some Linux work at the time, I too found the reception to kernel
changes to often be a tad cold (it took 10 years to get the core RDMA
support up-streamed). It's possible the way the OpenSSI team asked, the
prayers offered were not acceptable to those in charge at the time.  I
don't know, but please be careful here. *They were tried and feel that they
were rejected.*   *That is history*.  I understand that you want to try
to say, well there is no evidence of the proper emails/git change, *etc.*
 But that team ran into blocks.  So you can be a lawyer about it, or you
can try to accept what actually happened to those of us on the other end
with some grace.

FWIW: Larry M and I have often disagreed about the 'open-ness' of the
traditional UNIX releases from AT&T.   I suspect we are both right in our
position given the history that we each experienced.  Larry's position
(which I understand and accept) is that from his standpoint, it just was
not *open to him *as the University kept things under lock and key. I
always find that strange because I had absolutely the opposite history.  I
know my friend at MIT had free access, I can only assume you enjoyed that
yourself/but I'll not try to speak for you.  I believe it was available if
you had wanted it, while it was not Larry at UWis.

I do not know for sure in the case of the OpenSSI team, I know what they
have told me, but my >>guess<< is that something similar is happening
here.   The issue, which I think was similar to the pushback my teams
received with
RDMA around the same timeframe --> the core Linux kernel team was still
trying to fight to be a desktop war and had not yet started to focus on where
it would become a major success (enterprise-class system).   RDMA (and I
suspect OpenSSI too) was not seen as something that was relevant to the
desktop war and the creators were discouraged to continue to pursue it.

Taking my own experience here, RDMA only got upstreamed because so many
people at Intel started working in the Linux kernel team and people like me
at Intel who did care about that support, had to be a tad forceful to get
it there.  As I said, it took about 10 years before it came out. all
clustered Linux systems use it.   In my own experience when we started that
work in the early/mid-1990s, I personally was quite directly told [IIRC to]
'bugger off' in an email from one of the core Linux kernel folks (not you
mind you - but I bet you can guess) - that they were not interested in the
feature.  The word was something on the order of adding RDMA would only
make it hard for the VM system and no one would use it.  What is
interesting is that it's pretty popular and now a lot of hardware is being
designed assuming it is there and the Linux implementation frankly is the
most complete.  I've also seen a number of distros advertise their support
for RDMA HW these days.

Back to my core point.  Adding support for VPROC was invasive to the kernel
itself.  There is code to support processes in lots of places (For instance
the code to send different signals even makes it into some device
drivers).    So it means moving all the process code into separate modules
(like the file systems) and then making the core kernel call indirectly
through that layer.  Once that layer and functions are added, it means that
different process models (like a distributed one needed for something like
TNC) become a loadable module. Kernel's that do need it, just load the
traditional process model.  The other thing that is cool, IMO, it means you
can start to play with other process models.  Adding processes that use a
different API (*e.g.* my comment about the OS/2 demo we did for IBM).  Yes,
the changes are invasive to add support, but the power is extraordinary.

So ....   I also, personally know a number of the folks that worked on the
OpenSSI project and I suspect they tried to get the VPROC changes
upstreamed too, but were ignored/discouraged, and they finally gave up
trying.   I know at one point Frank started to put VPROC support into
FreeBSD, but I don't think that went anywhere either (although I don't
think he finished it).  I also know that the *Linux port to 2.6 was
complete at one point* (I personally had it running on a cluster here at
Intel with RDMA too BTW), but I never tried the FreeBSD codebase.

And yes, I do think that is a real shame and that it does not speak well of
history.  History has probably lost something good because at this point
the people involved are just not interested in trying anymore.

Clem
ᐧ

[-- Attachment #2: Type: text/html, Size: 8534 bytes --]