From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: tuhs-bounces@minnie.tuhs.org X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) 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,HEADER_FROM_DIFFERENT_DOMAINS,HTML_FONT_LOW_CONTRAST, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.1 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id c69b18f2 for ; Thu, 23 Aug 2018 17:25:45 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id D7011A1BA3; Fri, 24 Aug 2018 03:25:43 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id BF009A1A88; Fri, 24 Aug 2018 03:25:20 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (1024-bit key; unprotected) header.d=ccc.com header.i=@ccc.com header.b=O0U59tOp; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 6387BA1A88; Fri, 24 Aug 2018 03:25:19 +1000 (AEST) Received: from mail-io0-f172.google.com (mail-io0-f172.google.com [209.85.223.172]) by minnie.tuhs.org (Postfix) with ESMTPS id 9AFAAA1A85 for ; Fri, 24 Aug 2018 03:25:18 +1000 (AEST) Received: by mail-io0-f172.google.com with SMTP id n18-v6so4906910ioa.9 for ; Thu, 23 Aug 2018 10:25:18 -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 :cc; bh=mp0Lkm+/f0YTWm9LjcOkUAI0JOzCQqS47q9OfcR5mbU=; b=O0U59tOpNqR5xEmBbL7BiiL9n+E6GYv+puxJn0nqVLz76gr6WT/TwtvPPEIyRHdfpY qFjzBecn6ll1lLAxGBQnbUBPgUETwYNEDxcLCLTimGJy98ZBICSLisA39uKXmknh/f8H YkOP9l3vy6g9A2gzAomQU2TrHyCCTZJBAg5L8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mp0Lkm+/f0YTWm9LjcOkUAI0JOzCQqS47q9OfcR5mbU=; b=QKTSKj8xbCqYhmxzpLWmQSGnJKvzKpwIrOkyiL9Z3LTfpQoqEfOMK+81OfMWfWMAV8 h744YFiBA2e351X4LLMW+D4V/EZ4tavSnDLSfpUzzKegoTVMBVp3QQwypF8pJcwzJKK1 rNl3Ke/76ITYIWe2NvbdzG6WxdnYBHX9PSsJPihLQt4ByK8XfoJ+fRqHweDPiaozN38M qgdH+5Jym+1FoOm7V62qeSxPdJ4/liHMTSc0zITRom7B+uKw9w8zVLJ23JJjZJD1jjyI CcvIlaJNCqsyvbUQcOM3AxQOcADJahknOWBj+8LZTR5Xjs4CZeo9zqqxpcytFLxjz4R7 Ou+w== X-Gm-Message-State: APzg51BC/l/OjkrQFO2dex8RfKtrVdRDeMPipy8+DyfVYW9lBcTtQWkw gn2nF8nfy58ffxT/IQVIfhLLif/7ahdG+Dk1jbbCdCmX X-Google-Smtp-Source: ANB0Vdawh0CzWVWncOpOi3Rvc+Qf4UxIGOv5dHhNE9dvUK/+4ADm2WrwXjzz9FY1AJ11ZKhiEbK6CFnw+xRcFfL/7rY= X-Received: by 2002:a6b:9cc9:: with SMTP id f192-v6mr15216267ioe.284.1535045117865; Thu, 23 Aug 2018 10:25:17 -0700 (PDT) MIME-Version: 1.0 References: <10c401d43aef$8be34870$a3a9d950$@ronnatalie.com> In-Reply-To: <10c401d43aef$8be34870$a3a9d950$@ronnatalie.com> From: Clem Cole Date: Thu, 23 Aug 2018 13:24:51 -0400 Message-ID: To: Ronald Natalie Content-Type: multipart/alternative; boundary="000000000000f7150405741d8a66" Subject: Re: [TUHS] C++ / Kernel X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000f7150405741d8a66 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Aug 23, 2018 at 10:43 AM wrote: > I'm not sure what "strong typing" gain you expect to find. With the > exception of the void* difference, C++ isn't much more "type strong" than > C. > A lot of the type issues you can find on the Kernel just by turning up th= e > compiler warnings (or use lint). > 100% agree... > > The biggest issue we had was BSD didn't use void* at all. Had they > converted pointers to void*, which is in implementation necessarily the > same > as char*, > C would have done the right thing. The problem is they did what I call > "Conversion by union." > I just put it as 'silent architectural assumptions' in system's programming. In Henry's 10 commandments, he referred to this as assuming 'all the world is a Vax.' (today the assumption is all the world is INTEL*64). The DevSwitch is the beginnings of an object oriented philosophy. Alas, > the original UNIX used it only for mapping major dev numbers to functions= . > It got some later use for other things like multi filesystem > support. > Fair enough -- again. As much as I love BSD, I'm quick to knock it (and now Linux) a few pegs for two issues in this light. At the time, adding something like the file system switch was engious and novel. It took a couple of different schemes in different UNIX kernels (Sun, Masscomp, Eight edition and later System V) and then a couple of arguments on how to do interposition to stack them to settle on the proper functions needed for the FS, but eventually we mostly have them. But that took years, we still don't have something like the Locus vproc work for the process layer, although it was added to Linux as well as BSD/Mach [Linux rejected it - see the OpenSSI.org work]. To me, if we had done the same thing with the process layer that we did to FS's we would be better off. But the reason is off course the lack of an indirection layer which object give you. > > The scary supportability thing in the kernel, isn't so much typing, but t= he > failuer to "hide" implementation details of one part of the kernel from t= he > other. > Again, I agree. But this argument screams in favor of Dykstra THE style layering (e.g. micro-kernel) approach. I always thought it was a better way to go, but in the end, people always picked pure performance over the safety that "information hiding" gives you. It's tough, I've been on both sides of this debate and have empathy for both positions. As a supplier, it is all about being as fast as possible, because the customers don't care how hard you have to work, they just want as much speed as possible (in fact the super computer folks would really rather no OS at all). So the 'less is more' monolithic / hack / architectural specific ideas make a lot of sense. But some of the things we are talking about here are ideas that aid us in the development side on making 'better' or 'cleaner' systems - ones that are more maintainable and easier to ensure are 'correct' - which often the custom will not pay for, or worse shun because it end up being a little slower. Clem =E1=90=A7 --000000000000f7150405741d8a66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Aug 23, 2018 at 10:43 AM <ron@ronnatalie.com> wrote:
100= % agree...
=C2=A0 =C2=A0
=C2=A0

The biggest issue we had was BSD didn't use void* at all.=C2=A0 =C2=A0H= ad they
converted pointers to void*, which is in implementation necessarily the sam= e
as char*,
C would have done the right thing.=C2=A0 = =C2=A0The problem is they did what I call
"Conversion by union."=C2=A0 =C2=A0=C2=A0
I just put it as 'silent architectural assumptions' in system'= s programming.=C2=A0 =C2=A0In Henry's 10 commandments, he referred to t= his as assuming 'all the world is a Vax.'=C2=A0 (today the assumpti= on is all the world is INTEL*64).=C2=A0


The DevSwitch is the beginnings of an object oriented philosophy.=C2=A0 =C2= =A0Alas,
the original UNIX used it only for mapping major dev numbers to functions.<= br> It got some later use for other things like multi filesystem
support.
Fair enough -- again.=C2=A0 As = much as I love BSD, I'm quick to knock it (and now Linux) a few pegs fo= r two issues in this light.=C2=A0 At the time, adding something like the fi= le system switch was engious and novel.=C2=A0 =C2=A0It took a couple of dif= ferent schemes in different UNIX kernels (Sun, Masscomp, Eight edition and = later System V) and then a couple of arguments on how to do interposition t= o stack them to settle on the proper functions needed for the FS, but event= ually we mostly have them.=C2=A0 =C2=A0But that took years, we still don= 9;t have something like the Locus vproc work for the process layer, althoug= h it was added to Linux as well as BSD/Mach [Linux rejected it - see the Op= enSSI.org work].

To me, if we had done the same thing = with the process layer that we did to FS's we would be better off.=C2= =A0 But the reason is off course the lack of an indirection layer which obj= ect give you.


=C2=A0

The scary supportability thing in the kernel, isn't so much typing, but= the
failuer to "hide" implementation details of one part of the kerne= l from the
other.
Again, = I agree.=C2=A0 But this argument screams in favor of Dykstra THE style laye= ring (e.g. micro-kernel) approach.=C2=A0 =C2=A0I always thought it was a be= tter way to go, but in the end, people always picked pure performance over = the safety that "information hiding" gives you.

It's tough, I've been on both sides of this debate and have e= mpathy for both positions.=C2=A0 =C2=A0As a supplier, it is all about being= as fast as possible, because the customers don't care how hard you hav= e to work, they just want as much speed as possible (in fact the super comp= uter folks would really rather no OS at all).=C2=A0 So the 'less is mor= e' monolithic / hack / architectural specific ideas make a lot of sense= .=C2=A0 =C2=A0 But some of the things we are talking about here are ideas t= hat aid us in the development side on making 'better' or 'clean= er' systems - ones that are more maintainable and easier to ensure are = 'correct' - which often the custom will not pay for, or worse shun = because it end up being a little slower.

Clem
=C2=A0
3D""=E1=90=A7
--000000000000f7150405741d8a66--