The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Paul Ruizendaal <pnr@planet.nl>
To: TUHS main list <tuhs@minnie.tuhs.org>
Subject: [TUHS] Abstractions
Date: Sun, 21 Feb 2021 11:47:39 +0100	[thread overview]
Message-ID: <0D0EC7CA-0014-44D5-BABD-CF799F9D4418@planet.nl> (raw)

To quote from Jon’s post:

> There have been heated discussions on this list about kernel API bloat.  In my
> opinion, these discussions have mainly been people grumbling about what they
> don't like.  I'd like to flip the discussion around to what we would like.


> Ken and Dennis did a great job with initial abstractions.  Some on this list
> have claimed that these abstractions weren't sufficient for modern times.
> Now that we have new information from modern use cases, how would we rethink
> the basic abstractions?

I’d like to add the constraint of things that would have been implementable
on the hardware of the late 1970’s, let’s say a PDP11/70 with Datakit or
3Mbps Ethernet or Arpanet; maybe also Apple 2 class bitmap graphics.

And quote some other posts:

> Because it's easy pickings, I would claim that the socket system call is out
> of line with the UNIX abstractions; it exists because of practical political
> considerations, not because it's needed.  I think that it would have fit
> better folded into the open system call.

>> 
>> Somebody once suggested a filesystem interface (it certainly fits the Unix 
>> philosophy); I don't recall the exact details.
> 
> And it was done, over 30 years ago; see Plan 9 from Bell Labs....

I would argue that quite a bit of that was implementable as early as 6th
Edition. I was researching that very topic last Spring [1] and back ported
Peter Weinberger’s File System Switch (FSS) from 8th to 6th Edition; the
switch itself bloats the kernel by about half a kilobyte. I think it may be
one of the few imaginable extensions that do not dilute the incredible
bang/buck ratio of the V6 kernel.

With that change in place a lot of other things become possible:
- a Kilian style procfs
- a Weinberger style network FS
- a text/file based ioctl
- a clean approach to named pipes
- a different starting point to sockets

Each of these would add to kernel size of course, hence I’m thinking about
a split I/D kernel.

To some extent it is surprising that the FSS did not happen around 1975, as
many ideas around it were 'in the air' at the time (Heinz Lycklama’s peripheral
Unix, the Spider network Filestore, Rand ports, Arpanet Unix, etc). With the
benefit of hindsight, it isn’t a great code leap from the cdev switch to the
FSS - but probably the ex ante conceptual leap was just too big at the time.

Paul

[1] Code diffs here:
https://1587660.websites.xs4all.nl/cgi-bin/9995/vdiff?from=fab15b88a6a0f36bdb41f24f0b828a67c5f9fe03&to=b95342aaa826bb3c422963108c76d09969b1de93&sbs=1



             reply	other threads:[~2021-02-21 11:01 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-21 10:47 Paul Ruizendaal [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-02-24  4:18 Rudi Blom
2021-02-23 19:37 Nelson H. F. Beebe
2021-02-23 21:02 ` Charles H. Sauer
2021-02-23 21:15   ` Henry Bent
2021-02-24  2:47     ` Greg A. Woods
2021-02-24  3:20       ` Warner Losh
2021-02-24 20:05         ` Greg A. Woods
2021-02-24  1:51 ` Greg A. Woods
2021-02-24  2:23   ` Nelson H. F. Beebe
2021-02-20 23:09 M Douglas McIlroy
2021-02-21  8:15 ` Otto Moerbeek
2021-02-21 11:08 ` Rich Morin
2021-02-21 22:40 ` Dave Horsfall
2021-02-21 23:01   ` Steve Nickolas
2021-02-23  3:31     ` Andrew Warkentin
2021-02-22  0:13   ` Warren Toomey
2021-02-27  2:47     ` Dave Horsfall
2021-02-23  0:25   ` Wesley Parish
2021-02-23  0:38     ` Steve Nickolas
2021-02-23  2:50       ` Theodore Ts'o
2021-02-23  3:19         ` Warner Losh
2021-02-23  1:47     ` Theodore Ts'o
2021-02-21 22:54 ` Clem Cole
2021-02-15 19:56 Jon Steinhart
2021-02-15 21:52 ` Dave Horsfall
2021-02-16  7:13   ` arnold
2021-02-16  8:15 ` Tom Ivar Helbekkmo via TUHS
2021-02-16 10:04   ` Wesley Parish
2021-02-16 19:59   ` Jon Steinhart
2021-02-17  4:01     ` Theodore Ts'o
2021-02-17  6:50     ` Chris Hanson
2021-02-16 12:26 ` Rich Morin
2021-02-16 22:46 ` Steffen Nurpmeso
2021-02-17 12:09 ` David Arnold

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0D0EC7CA-0014-44D5-BABD-CF799F9D4418@planet.nl \
    --to=pnr@planet.nl \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).