What kinds of things would you want in the GNU OS?

[Frank Mayhar]

In article <106326 at 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!  :-)

}What kinds of features or design rationale should it use?
}For instance:
}
}File system:	SysV vs Berkeley? Something better?
}		Embedded file types? >32-bit file offsets?

Something better, but compatible, at least at some level.  How about
embedding B-tree indexed file structure in the file system?  (This
would let you do things like use strings to lookup records in a file,
even from the kernel.  Might also let you have sorted (*gasp*)
directories.)  Some sort of symbolic link idea might be nice.  Use
a global directory concept for maintaining subdirectories, to speed
directory searches.  And let mounted file systems span devices!

}Security:	ACLs? Get rid of root? Security monitors? Auditing?
}		Provably secure(A1)?

Better security is always a good thing.  Security's not my forte, so
I'll leave it alone.

}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.

}Virtual Memory:	Should GNU run on non-VM machines? Algorithm ideas?
}		How general (map *everything* into VM space, like Multics)?
}		Shared libraries?

I like the SunOS virtual memory concept (minus the current crop of bugs, of
course).  If you're writing a Real Operating System, why worry about machines
that won't support virtual memory.  Hell, by the time Gnu is ready, non-VM
machines will probably be a thing of the past anyway.  Shared libraries
are good.  Shared instruction space (text?) is another good idea, that can
help save on memory requirements for often-used programs.

}Networking:	NFS? RFS? Something better?
}		Interfaces: Streams? TLI? Something better?
}		TCP/IP? OSI? SAA/SNA:-)?
}		RPC Services? What kind?

Something better.  But don't ask me what.  NFS is OK, but it has problems.
You would want to support TCP/IP, at least at first (maybe using the BSD
code), but OSI is probably the way to go.  SNA makes me gag.  (Actually,
all of IBM makes me gag. :-)

}Overall Design:	What nice ideas from other OSes could we use?
}		Multics? VMS? VM? DG/OS?
}		Fault tolerance?

See above.  A lot of these ideas come from the way a particular mainframe
operating system was designed.  An OS which is going the way of the Dodo,
unfortunately.  Name withheld to protect the guilty.

}How about this? Make everything a user process which serves
}a resource to a client. Resources include the CPU (scheduler),
}memory (VM), disk (file system), network (sockets, etc),
}serial lines (terminal handlers), etc. Each server determines the access
}method and security criteria for its service. Make no arbitrary policy
}decisions regarding a service! Don't like the VM server? Replace it! You
}could have a security monitor provide a security policy on behalf of
}your file system or IPC mechanisms. If you have no need for security,
}don't run the monitor.

Excellent idea!  Promotes modularity, and allows flexibility.  Almost a
plug-and-play operating system.  One problem, though:  there would have
to be some sort of privilege level system, so that the resource handlers
can do things like write other user's memory, directly access devices,
re-map memory, etc.  And you would have to provide at least minimal
functions in each module in the initial release.  Not everybody is
an OS developer.

That's my $2.95 worth.  Next?
-- 
Frank Mayhar  ..!uunet!ladcgw!frank (frank at ladc.bull.com)
              Bull HN Los Angeles Development Center
              5250 W. Century Blvd., LA, CA  90045  Phone:  (213) 216-6241