17 Feb
2021
17 Feb
'21
1:59 a.m.
Tom Ivar Helbekkmo writes:
Jon Steinhart <jon(a)fourwinds.com> writes:
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
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.