There is a meta-issue here in the discussion over software modems and
scheduling that I think is being missed.

NetBSD gets used in many different contexts, but I think we can safely
characterize them into two categories:

1. traditional multi-user time-sharing
2. single-user system (as in one user, not "single-user mode")

There is, of course, a range in between those two extremes, with some
variations. For purposes of argument, I'll lump pure Internet servers (e.g.
SMTP relays, web or FTP servers) into the multi-user category, since there
are generally multiple users, even if they don't show up in utmp.

Timesharing is all about fairness in allocating computing resources. As
laudable as this attitude is, it gets in the way when you begin to talk
about single-user machines and real-time system response. The strong desire
here to make sure that no single process can ever eat the whole machine is
an example of this. I "grew up" in those environments and have a lot of the
same attitude ingrained.

By contrast, the comments about mouse-handling in the Amiga are typical of
the single-user approach; the MacOS is similar - if the mouse stops
tracking, you know your system is toast, and not just thrashing. From where
I sit, this is a very desireable behavior in such a system - I'm at the
console (display, keyboard, mouse) and the system should respond to *me*,
damnit!

There are other issues tied up in this, of course: for example, to the
extent that we can do so, we should strive to minimize the number of
instructions executed at any interrupt-masking priority, whether in an
interrupt service routine, in an spl() protected section. Fortunately, this
class of work shows benefits system-wide, regardless of what scheduler
you're using.

There are more than enough applications that need guaranteed response time
or guaranteed CPU slices that we ought to put in some minimal scheduling
support for them. However, that doesn't mean we have to abandon the
existing time-sharing scheduler - we just need to make the system scheduler
a selectable module, depending upon the system behavior desired. That sort
of architecture would also make it easier to experiment with different
scheduling policies.

	Erik <fair@clock.org>