The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Jon Steinhart <jon@fourwinds.com>
Cc: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] Abstractions
Date: Tue, 16 Feb 2021 23:01:32 -0500	[thread overview]
Message-ID: <YCyVHI5LNorkHos5@mit.edu> (raw)
In-Reply-To: <202102161959.11GJxWC5676454@darkstar.fourwinds.com>

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

  reply	other threads:[~2021-02-17  4:02 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2021-02-17  6:50     ` Chris Hanson
2021-02-17  4:06   ` [TUHS] SQL OS (Re: Abstractions Bakul Shah
2021-02-16 12:26 ` [TUHS] Abstractions Rich Morin
2021-02-16 22:46 ` Steffen Nurpmeso
2021-02-17 12:09 ` David Arnold
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-21 10:47 Paul Ruizendaal
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-24  4:18 Rudi Blom

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=YCyVHI5LNorkHos5@mit.edu \
    --to=tytso@mit.edu \
    --cc=jon@fourwinds.com \
    --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).