Re: [TUHS] Abstractions

[David Arnold <davida@pobox.com>]

> 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