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

On Mon, May 2, 2022 at 10:46 AM tytso &lt;tytso(a)mit.edu&gt; wrote: 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 ᐧ