[TUHS] Abstractions

[TUHS] Abstractions

[Jon Steinhart]

Was thinking about our recent discussion about system call bloat and such.
Seemed to me that there was some argument that it was needed in order to
support modern needs.  As I tried to say, I think that a good part of the
bloat stemmed from we-need-to-add-this-to-support-that thinking instead
of what's-the-best-way-to-extend-the-system-to-support-this-need thinking.

So if y'all are up for it, I'd like to have a discussion on what abstractions
would be appropriate in order to meet modern needs.  Any takers?

Jon

Re: [TUHS] Abstractions

[Dave Horsfall]

On Mon, 15 Feb 2021, Jon Steinhart wrote:

[...]

> So if y'all are up for it, I'd like to have a discussion on what 
> abstractions would be appropriate in order to meet modern needs.  Any 
> takers?

Somebody once suggested a filesystem interface (it certainly fits the Unix 
philosophy); I don't recall the exact details.

-- Dave

Re: [TUHS] Abstractions

[arnold]

Dave Horsfall <dave@horsfall.org> wrote:

> On Mon, 15 Feb 2021, Jon Steinhart wrote:
>
> [...]
>
> > So if y'all are up for it, I'd like to have a discussion on what 
> > abstractions would be appropriate in order to meet modern needs.  Any 
> > takers?
>
> Somebody once suggested a filesystem interface (it certainly fits the Unix 
> philosophy); I don't recall the exact details.
>
> -- Dave

And it was done, over 30 years ago; see Plan 9 from Bell Labs....

Arnold

Re: [TUHS] Abstractions

[Tom Ivar Helbekkmo via TUHS]

Jon Steinhart <jon@fourwinds.com> writes:

> So if y'all are up for it, I'd like to have a discussion on what
> abstractions would be appropriate in order to meet modern needs.  Any
> takers?

A late friend of mine felt strongly that Unix needed an SQL interface to
the kernel.  With all information and configuration in a well designed
schema, system administration could be greatly enhanced, he felt, and
could have standard interaction patterns across components -- instead of
all the quirky command line interfaces we have today, and their user
oriented output formats that you need to parse to use the data.

sysctl done right, so to speak.

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

Re: [TUHS] Abstractions

[Wesley Parish]

Now that is an interesting idea. Did he ever get around to developing 
it? Any documents? Any experimental results? (Mind you, he'd've run into 
CJ Date's reservations on the incompleteness of SQL as a language stuck 
between relational algebra and relational calculus ... :) )

Wesley Parish

On 16/02/21 9:15 pm, Tom Ivar Helbekkmo via TUHS wrote:
> Jon Steinhart <jon@fourwinds.com> writes:
>
>> So if y'all are up for it, I'd like to have a discussion on what
>> abstractions would be appropriate in order to meet modern needs.  Any
>> takers?
> A late friend of mine felt strongly that Unix needed an SQL interface to
> the kernel.  With all information and configuration in a well designed
> schema, system administration could be greatly enhanced, he felt, and
> could have standard interaction patterns across components -- instead of
> all the quirky command line interfaces we have today, and their user
> oriented output formats that you need to parse to use the data.
>
> sysctl done right, so to speak.
>
> -tih

Re: [TUHS] Abstractions

[Jon Steinhart]

Tom Ivar Helbekkmo writes:
> Jon Steinhart <jon@fourwinds.com> writes:
>
> > So if y'all are up for it, I'd like to have a discussion on what
> > abstractions would be appropriate in order to meet modern needs.  Any
> > takers?
>
> A late friend of mine felt strongly that Unix needed an SQL interface to
> the kernel.  With all information and configuration in a well designed
> schema, system administration could be greatly enhanced, he felt, and
> could have standard interaction patterns across components -- instead of
> all the quirky command line interfaces we have today, and their user
> oriented output formats that you need to parse to use the data.
>
> sysctl done right, so to speak.

OK, that's interesting and makes my brain a bit crazy.  Are we talking

 select file_descriptor from file_table where file_name='foo' && flags='O_EXCL';
 delete from process_table where process_id=pid;

and so on?  Lots of possibilities for weird joins.

But, this wasn't exactly what I was looking for in my original post which was
maybe too terse.

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?

Quoting from something that I wrote a few years ago:

	The original Apple Macintosh API was published in 1985 in a three-­
	volume set of books called Inside Macintosh (Addison-­Wesley). The
	set was over 1,200 pages long. It’s completely obsolete; modern
	(UNIX-based) Macs don’t use any of it. Why didn’t this API
	design last?

	By contrast, version 6 of the UNIX operating system was released 10
	years earlier in 1975, with a 321-page manual. It embodied a completely
	different approach that sported a narrow and deep API.

	Both the UNIX API and a large number of the original applications are
	still in widespread use today, more than 40 years later, which is a
	testament to the quality of the design. Not only that, but a large
	number of the libraries are still in use and essentially unchanged,
	though their functionality has been copied into many other systems.

While I don't have a count of the number of entries in the original Mac API,
I'm guessing that number of Linux system calls is getting closer to that
number.

Is there any way that the abstractions can be rethought to get us back to an
API that more concise and flexible?  By flexible I mean the ability to support
new functionality without adding more system calls?

While the SQL interface notion is interesting, to me it's more in line with
using a different language to access the API.  But it would be interesting to
see it fleshed out because maybe the abstractions provided by various tables
would be different.

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.

Something else added along with the networking was readv/writev.  In this case,
I would claim that those are the correct modern abstraction and that read/write
are a subset.

Hope that clarifies the discussion that I'm trying to kick off.

Jon

Re: [TUHS] Abstractions

[Theodore Ts'o]

It's always useful to talk about requirements as the first part of the
design process.

At the high level, how important is backwards compatibility?  Is the
problem of how support existing application in scope, or not?  Or is
the assumption that emulation libraries will always be sufficient.

How about performance, either of applications using the new API, or
applcications using the legacy API's?  And what are the hardware
platforms that this new set of abstractions going to target?  Is the
goal only to target small embedded systems?  Mobile handsets?  Desktop
systems?  Is it supposed to be able to scale to super computers?  Are
web front-ends that need to be able to accept thousands of incoming
TCP connections per second, and then redirect those connections to
application logic servers in scope?

Solutions that involve being able to support intpret general SQL
queries may not scale in terms of performance and the ability to
support thousands of file descriptors in a single process.

Backwards compatibility is why we have multiple asynchronous I/O
interfaces --- from select, poll, epoll, kqueue, and io_uring.  And
the reason why we've had multiple asynchronus I/O interfaces over the
decades is because the performance requirements have changed, and the
capability of hardware interfaces for high performance I/O has
changed; it's no longer about I/O ports and interrupts, but instead,
having multiple request and response queues through memory mapped I/O,
and the need to be able to use multiple CPU's and multiplexing
multiple network or storage transactions across a single doorbell or
system call.

If all of this is out of scope, then the design process will be much
simpler, and perhaps more elegant; but the resulting design will not
be useful for many of the use cases where Linux is used today.  And
perhaps that's OK.  On the other hand, one person's simple, elegant
design is another person's toy that isn't fit for their purpose.

IBM once said that part of Linux's power is that it scales from wrist
watches to super computers.  Is that in scope for this theoretical
design question?

						- Ted

Re: [TUHS] Abstractions

[Chris Hanson]

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

On Feb 16, 2021, at 11:59 AM, Jon Steinhart <jon@fourwinds.com> wrote:
> 
> 	The original Apple Macintosh API was published in 1985 in a three-­
> 	volume set of books called Inside Macintosh (Addison-­Wesley). The
> 	set was over 1,200 pages long. It’s completely obsolete; modern
> 	(UNIX-based) Macs don’t use any of it. Why didn’t this API
> 	design last?

I think this is a little bit of a red herring; most of the original Macintosh Toolbox APIs would not be considered "system calls" then or now. The Macintosh Operating System APIs were a much more tightly-scoped set on top of which was the Toolbox.

For example, in the original filesystem and device driver interfaces, you had _PBOpen, _PBClose, _PBRead, _PBWrite, and _PBControl. Sound familiar? One major difference is that these took a struct full of arguments (a parameter block in Macintosh API terminology) and could be used either synchronously or asynchronously with a callback, unlike the core UNIX filesystem calls.

A more oranges-to-oranges comparison would be to look at the Macintosh Operating System and Toolbox API surface compared with, say, the SunOS and SunWindows API surface…

And then, of course, there's the question of how long the design lasted: The Carbon API set is a direct descendant of the original Macintosh Operating System and Toolbox API set, and was supported for the entire lifetime of 32-bit executables on the Mac. I ported plenty of OS & Toolbox code to Carbon and it was mostly a matter of updating UI metrics and replacing direct structure accesses with equivalent function calls.

  -- Chris



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

[TUHS] SQL OS (Re: Abstractions

[Bakul Shah]

On Feb 16, 2021, at 12:15 AM, Tom Ivar Helbekkmo via TUHS <tuhs@minnie.tuhs.org> wrote:
> 
> Jon Steinhart <jon@fourwinds.com> writes:
> 
>> So if y'all are up for it, I'd like to have a discussion on what
>> abstractions would be appropriate in order to meet modern needs.  Any
>> takers?
> 
> A late friend of mine felt strongly that Unix needed an SQL interface to
> the kernel.  With all information and configuration in a well designed
> schema, system administration could be greatly enhanced, he felt, and
> could have standard interaction patterns across components -- instead of
> all the quirky command line interfaces we have today, and their user
> oriented output formats that you need to parse to use the data.

Not quite the same but Arthur Whitney, the author of the K array
programming language did something called kOS, mainly to run K apps.
It initially ran on Linux but then on "bare metal". The entire OS +
a graphic layer called z (to replace X11) fit in 62kB. But it seems
he never released it. No idea why. kdb (built on top of K) is a
columnar database. An old article on kOS.

http://archive.vector.org.uk/art10501320

Also note that in mid 80s there was at least one company building
Unix with atomic transactions IO. I forget their name now -- it was
Tolerant Systems or Relational Systems or something. As a contractor
I wrote some testing framework for them for regression testing etc.
As I recall the OS was quite slow. There were a bunch of Unx 
workstations startups in the Silicon Valley in '80s. Not sure their
stories have been told (and I knew only a few bits and pieces that
I picked up as a contractor and forgot soon).

Re: [TUHS] Abstractions

[Rich Morin]

> On Feb 15, 2021, at 11:56, Jon Steinhart <jon@fourwinds.com> wrote:
> 
> Was thinking about our recent discussion about system call bloat and such.
> Seemed to me that there was some argument that it was needed in order to
> support modern needs.  As I tried to say, I think that a good part of the
> bloat stemmed from we-need-to-add-this-to-support-that thinking instead
> of what's-the-best-way-to-extend-the-system-to-support-this-need thinking.
> 
> So if y'all are up for it, I'd like to have a discussion on what abstractions
> would be appropriate in order to meet modern needs.  Any takers?

The folks behind the Nerves Project (https://www.nerves-project.org) have done some serious thinking about this question, albeit mostly confined to the IoT space.  They have also written (and distribute) some nifty implementation code.

I won't try to cover all of their work here, but some high points include:

- automated build and cross-compilation of entire Linux-based systems
- automated distribution of (and fallbacks for) updated system code
- separation of code and data using read-only and read/write file systems
- support for multiple target platforms (e.g., processors, boards)

- Erlang-style supervision trees (via Elixir) for critical services, etc.
- extremely rapid boot times for the resulting (Linux-based) systems

For more information, check out their web site, watch some presentations,
and/or (gasp!) try out the code...

-r
   

Re: [TUHS] Abstractions

[Steffen Nurpmeso]

Jon Steinhart wrote in
 <202102151956.11FJuRIh3079869@darkstar.fourwinds.com>:
 |Was thinking about our recent discussion about system call bloat and such.
 |Seemed to me that there was some argument that it was needed in order to
 |support modern needs.  As I tried to say, I think that a good part of the
 |bloat stemmed from we-need-to-add-this-to-support-that thinking instead
 |of what's-the-best-way-to-extend-the-system-to-support-this-need thinking.
 |
 |So if y'all are up for it, I'd like to have a discussion on what abstrac\
 |tions
 |would be appropriate in order to meet modern needs.  Any takers?

Proper program exit integer status codes.
Now that "set -o pipefail" is a standardized feature of POSIX
shells all that is needed are programs which properly handle
errors and also report that to the outside.  This is very hard,
especially when put over existing codebases.

But also new code.  For example i use BTRFS (with a long term
perspective to switch to ZFS, because of restartable snapshot
sends, and also because of ZFS encrypted partitions to replace my
several encfs-encrypted on-demand storages, these now can even be
shared in between FreeBSD and Linux), (i use it at all because it
ships with the Linux kernel, can be compiled-in, is
copyright-compatible, that is i wanted to test that coming from
over two decades of ext2/3/4 on Linux and of course the default of
FreeBSD, and i really drive the entire thing with subvolumes, only
the EFI boot partition is truly separate), anyhow, receiving
snapshots can fail but the snapshot counts as having been properly
received, and no exit status whatsoever will report the failure.
(At least in my practical experiences.)
Easy scriptability with proper (also meaning automatically
interpretable) error reports.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [TUHS] Abstractions

[David Arnold]

> On 16 Feb 2021, at 06:56, Jon Steinhart <jon@fourwinds.com> wrote:
> 
> Was thinking about our recent discussion about system call bloat and such.
> Seemed to me that there was some argument that it was needed in order to
> support modern needs.  As I tried to say, I think that a good part of the
> bloat stemmed from we-need-to-add-this-to-support-that thinking instead
> of what's-the-best-way-to-extend-the-system-to-support-this-need thinking.
> 
> So if y'all are up for it, I'd like to have a discussion on what abstractions
> would be appropriate in order to meet modern needs.  Any takers?

Plan9 showed that it’s possible to evolve the Unix model to encompass new needs without compromising the abstraction, although to be fair, it basically addressed only the first 15-20 years of changes since V7.  Freedom to break backward compatibility is obviously a key enabler, and difficult to manage for a commercial system. 

Despite its various issues, I think the Mach abstractions also stand up well as an insightful effort for their time.

One area that has continued to evolve in Unix, with a trail of (mostly) still-supported-but-no-longer-recommended APIs, is asynchronous event handling.  mpx, select, poll, kevents, AIO, /dev/poll, epoll, port_create, inotify, dnotify, FEN, etc.  What a mess!

Containers, jails, zones, namespaces, etc, is another area with diverse solutions, none of which have been sufficiently the Right Thing to be adopted by everyone else.

For today’s uses and hardware, the Unix API does too much: rich, stateful APIs copying everything from userland to kernel and back again — the context switching and data copying time is prohibitive, and so the kernel ends up being bypassed once it’s checked the permissions and allocated the hardware resources.  I hesitate to call it a micro-kernel model, but the kernel is used less, and libraries and services take on more of the work.





d