17 Feb
2021
17 Feb
'21
1:09 p.m.
On 16 Feb 2021, at 06:56, Jon Steinhart
<jon(a)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