Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!rutgers!rochester!rit!cci632!tvf
From: tvf@cci632.UUCP (Tom Frauenhofer)
Newsgroups: comp.unix.wizards
Subject: Re: What kinds of things would you want in the GNU OS?
Keywords: GNU OS features kernel fun!
Message-ID: <28855@cci632.UUCP>
Date: 26 May 89 17:29:17 GMT
References: <106326@sun.Eng.Sun.COM> <422@ladcgw.ladc.bull.com>
Reply-To: tvf@ccird7.UUCP (Tom Frauenhofer)
Organization: CCI, Communications Systems Division, Rochester, NY
Lines: 43

In article <422@ladcgw.ladc.bull.com> frank@ladc.bull.com (Frank Mayhar) writes:
>In article <106326@sun.Eng.Sun.COM> bitbug (James Buster) writes:
>}What kinds of things should be in the GNU Kernel?
>Oh boy!  Now you've asked for it!  :-)

"Oh boy!" is right! :-)

>}What kinds of features or design rationale should it use?
>}For instance:
>}Scheduler:	Real-time support? Task-driven? Event driven?
>}		Direct brain hookups:-)?
>How about scheduling processes on a per-login basis, rather than
>per-process.  I.e. a user has a certain quantum that is divided
>between all the processes he starts.  (It should be configurable,
>and maybe even adjustable on the fly by a privileged user.)  This
>would keep one user from starting sixteen compiles and bringing a
>system to its knees.

Fair to users, maybe.  How would you handle daemons?  Is each daemon its
own process group?  Or can they be grouped together somehow?

Even if you do this, the processes will still get in the way of each other
due to paging requirements.  You would have to go to a local paging/working
set system to cut out this interaction.  This is a gain if one of your goals
is real-time, but it requires a more intelligent user who can determine an
optimum working set size.

Another way processes interfere with each other is the kernel call mechanism
that UNIX uses where (I recall, mucho simplified) when one process is making
a kernel call others cannot (unless, of course, the process in the kernel is
blocked for some reason, say on a semaphore or because it is waiting on an
I/O call to be serviced).

All of the above have been done in various OS's.  It all boils down to the
goals of the GNU team (which is point I don't know much about).  Do they
want to emulate UNIX?  Or do they want to come up with something different?
It would be nice to see their design goals spelled out.

Mind you, none of this will affect the GNU kernel design one whit...

Thomas V. Frauenhofer	...!rutgers!rochester!cci632!ccird7!tvf
*or* ...!rochester!cci632!ccird7!frau!tvf *or* ...!rochester!rit!anna!ma!tvf1477
FRAU BBS: (716) 227-8094 2400/1200/300 baud - log in as "new" to register