Subject: Re: NetBSD system use characterization and scheduling
To: None <firstname.lastname@example.org>
From: Lucio de Re <email@example.com>
Date: 09/23/1998 08:01:31
According to Jukka Marin:
> Maybe that too, but how about having two schedulers simultaneously: One
> simple scheduler to run the real-time stuff (or semi-real-time, whatever)
> and when there are no such processes ready to run (or they have used up
> too much time recently), the normal scheduler would run normal processes.
> Something like creating a new level of things between interrupts and
I think we're falling into a fallacy here (my opinion), in that we
expect a general purpose OS to be all things to all people.
I liked Charles Hannum's suggestion (I have actually let it slip out of
my mind, but the idea of running NetBSD in my telephone sounded quite
promising), but in particular I think we should be looking at divergent
offsprings of NetBSD to handle distinct requirements.
For example, NetBSD as it stands now (I'm at 1.3.2) is a better than
adequate multiuser OS. Suggestions have been made about that a
workstation implementation should be more responsive to the single
user, and I have no doubt that many of us also use NetBSD in this role,
so they should be accommodated.
Similarly, there is scope for NetBSD (or somesuch) as a dedicated file
server (the idea is Plan 9's and I heartily support it), as well as
NetBSD (or perhaps FreeBSD is more appropriate, but I prefer NetBSD's
IP filtering and NAT style) as the platform for network firewalling.
Lastly, we have Charles wrestling with multiprocessing issues. I think
the latter is the place where real-time responsiveness can be
considered, even if it entails building on a MACH-like microkernel that
switches from real-time demands to scheduled tasks.
Just a few thoughts; to me a map of future developements in NetBSD may
make it easier to differentiate between immediate issues and long-term
objectives, as well as lay down some expected delivery dates.