From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HTML_FONT_LOW_CONTRAST,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 11435 invoked from network); 2 May 2022 15:41:02 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 2 May 2022 15:41:02 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 493139D461; Tue, 3 May 2022 01:41:01 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 8A6629D431; Tue, 3 May 2022 01:39:03 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (1024-bit key; unprotected) header.d=ccc.com header.i=@ccc.com header.b="n2v/W7/v"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id BC72A9D431; Tue, 3 May 2022 01:38:59 +1000 (AEST) Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) by minnie.tuhs.org (Postfix) with ESMTPS id 130149CE23 for ; Tue, 3 May 2022 01:38:59 +1000 (AEST) Received: by mail-qt1-f169.google.com with SMTP id x22so6239476qto.2 for ; Mon, 02 May 2022 08:38:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=L5LTFv83p+z5oepIKHRCZ7M6y6tw/F0fN1Isi5e2HyE=; b=n2v/W7/vYx7Oxr8ljxJbJTIil0kEyneeXwJ3ViCNP7/vNJY2fmShYL6Cxq4i3OZ2Aj cvexjNBqojqHIILr8dURhX3spttMjRkXO6V2pieVE0Vjp5UQ9OYKWd+excWnBVtG5mym 9AvswvIsl2RhihskiyjR0Zt8xcoWppwtevu2w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=L5LTFv83p+z5oepIKHRCZ7M6y6tw/F0fN1Isi5e2HyE=; b=uDEqGUDajiXPOrse0RulQixb5ThZjBrcLeZW8UHefRqbYVi3XbjJ9PE486k9gpev6n n7ohV28b4WecoB2hh0roxi2NjNbL0Lcin3bHAMEbjVyDsrpUSa+MIfRkWE0s9ktzdI8g lHxV9Hc0PTu4yNCLWfCBXrPwd+5Pxg0fo4krttgH7KlAnpAtGVj2xOJHx+h9Ae1hqnu+ U1U4KL52DAcsfk7Wv0CWx/mc974kaOcVQkPyv2WpOyGAYU5LyBp6oDFIxOpaAKwBW1SL WMEd0uZLmrfsyZjuKRLrj56tKxjGYY+2Z+aH29rnyyoGHssX+//RPSZAaAouPrLC5zKx Qq+A== X-Gm-Message-State: AOAM530XooSbZksZMVMZWxEh0Z2GlOtfspWDgR7GTOrvASDhftq47nH3 ifn9Cx6cfVdqERimuOEz54Vr0j9J8riTlsBfd4Ny5078T99WgMZX X-Google-Smtp-Source: ABdhPJyofj68jY39LPvVOUIrGaIatyfbz40JC6hDibV9ruItrQJyYXsT6F5k4lFYt24/heizyKqZCFy8xyggWJZnveg= X-Received: by 2002:ac8:5a4a:0:b0:2f3:9ddf:2cdd with SMTP id o10-20020ac85a4a000000b002f39ddf2cddmr8721302qta.112.1651505937790; Mon, 02 May 2022 08:38:57 -0700 (PDT) MIME-Version: 1.0 References: <57977CE7-DDCC-4861-BBD2-843B9B9F51C2@ronnatalie.com> <202205020242.2422g30m074857@ultimate.com> <2815597f-e1f2-498f-b0c3-763952ac734e@www.fastmail.com> In-Reply-To: From: Clem Cole Date: Mon, 2 May 2022 11:38:31 -0400 Message-ID: To: tuhs@minnie.tuhs.org Content-Type: multipart/alternative; boundary="000000000000c44f1705de0930aa" Subject: Re: [TUHS] First Unix-like OSes not derived from AT&T code? X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000c44f1705de0930aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, May 2, 2022 at 10:46 AM tytso 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 whe= re 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 =E1=90=A7 --000000000000c44f1705de0930aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, May 2, 2022 at 10:46= AM tytso <tytso@mit.edu> wrote:=
So it appears t= hat it was not a
matter of "the upstream Linux kernel team.... [being] willing to take<= br> the VPROC changes", it was more like no one asked, or prepared patches=
that could be considered by usptream.
FWIW:=C2=A0 I know that at least 3 people on the OpenSSI team = were telling me they were told to go away.=C2=A0 =C2=A0I do not know the de= tails of the interchange, but doing some Linux work at the time, I too foun= d 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=C2=A0way t= he=C2=A0OpenSSI team asked, the prayers offered were not acceptable to thos= e in=C2=A0charge at the time.=C2=A0 I don't know, but please be careful= =C2=A0here. They were tried and feel that=C2=A0they were rejected.=C2=A0 =C2=A0That is history.=C2=A0 I understand that yo= u want to try to=C2=A0say, well there is no evidence of the proper emails/g= it change, etc.=C2=A0 =C2=A0But that team ran into blocks.=C2=A0 So = you can be a lawyer about it, or you can try to accept=C2=A0what actually h= appened to those of us on the other end with some grace.

FWIW: Larry M and I have often disagreed about the 'op= en-ness' of the traditional UNIX releases from AT&T.=C2=A0 =C2=A0I = suspect we are both right in our position given the history that=C2=A0we=C2= =A0each=C2=A0experienced.=C2=A0 Larry's position (which I understand an= d accept) is that from his standpoint, it just was not open to him=C2= =A0as the University kept things under lock and key. I always find = that strange because I had absolutely the opposite history.=C2=A0 I know my= =C2=A0friend at MIT had free access,=C2=A0I can only assume you enjoyed tha= t yourself/but I'll not try to speak for you.=C2=A0 I believe it was av= ailable if you had wanted it,=C2=A0while it was not Larry at UWis.=C2=A0

<= div>I do not know for sure in the case of the O= penSSI team, I know what they have told me, but my >>guess<< is= that something similar is happening here.=C2=A0 =C2=A0The iss= ue, which I think was similar to the pushback my teams=C2=A0rece= ived=C2=A0with RDMA around=C2=A0the same timefram= e --> the core Linux kernel team was=C2=A0still trying=C2=A0to f= ight to be a desktop war=C2=A0and had not yet started to focus on=C2=A0where it would become a major success (enterprise-class system).=C2= =A0 =C2=A0RDMA (and I suspect OpenSSI too) was not se= en=C2=A0as something that was relevant to the desktop war and th= e creators were discouraged to continue to pursue it.=C2=A0=C2=A0

Taking my own experience here, RDMA only got upstreamed b= ecause 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 f= orceful to get it there.=C2=A0 As I said, it took about 10 years before it = came out. all clustered Linux systems use it.=C2=A0 =C2=A0In my own experie= nce when we started that work in the early/mid-1990s, I personally was quit= e 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.=C2=A0 The word was=C2=A0something= on the order of adding RDMA would only make it hard for the VM system and = no one would use it.=C2=A0=C2=A0What 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.=C2= =A0 I've also seen a number of distros advertise their support for RDMA= HW these days.=C2=A0

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

So ..= ..=C2=A0 =C2=A0I also, personally know a number of the folks that worked on= the OpenSSI project and I suspect they tried to get the VPROC changes upst= reamed too,=C2=A0but were ignored/discouraged, and they finally gave up try= ing.=C2=A0 =C2=A0I know at one point Frank started to put VPROC support int= o FreeBSD, but I don't think that went anywhere either (although I don&= #39;t think he=C2=A0finished it).=C2=A0 I also know that the Linux port = to 2.6 was complete at one point (I personally had it running on a clus= ter here at Intel with RDMA too BTW), but I never tried the FreeBSD codebas= e.

And yes, I do think that is a real sha= me and that it does not speak well of history.=C2=A0 History has probably l= ost something good because at this point the people involved are just not i= nterested in trying anymore.

Clem<= /span>
3D""=E1=90=A7
--000000000000c44f1705de0930aa--