Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mitel!sce!cognos!dgbt!gandalf!ml
From: ml@gandalf.UUCP (Marcus Leech)
Newsgroups: comp.unix.wizards
Subject: New (GNU) kernels--what I think
Keywords: UNIX progress; controversy
Message-ID: <2501@gandalf.UUCP>
Date: 29 May 89 20:27:05 GMT
Organization: Gandalf Data Ltd, Product Development
Lines: 113


There has been some discussion lately about "what you'd like to see in the
  GNU kernel".  Here's what I'd like to see in "the next great version of
  UNIX"--GNU or otherwise. It's kinda long--hit 'n' now if this sort of thing
  bores you.


    There are several areas that I'd like to see addressed.

User-interface:
    Make a sweep of all the commands in the system and decide on a consistent
 command-line options scheme that has the following attributes.  Options should
 be case insensitive.  Options that perform the same function in different
 commands should have the same names.  Options should be complete words, with
 a minimum-unambiguous scheme to reduce typing. Getopt() is certainly a
 reasonable starting point for this sort of thing.  Commands should all use
 perror(), wherever possible.  Commands should print a useful Usage: message
 when they are handed something they don't understand--"Huh?" just doesn't
 cut it.  In general, the messages coming out of programs should walk that
 fine-line between brevity, and useful information content.
 Interactive subsystems (editors, mailers, etc) should follow the
 same rules as for non-interactive commands, wherever possible.  Interactive
 subsystems should always provide a decent "help" facility.

Documentation:
  The online help should be better.  Either an entirely new facility needs to
  be added, or MAN needs to have better indexing.  The MANuals should be
  swept for inconsistencies between what they state, and reality.  There needs
  to be a better index.  The one-line command summary that is used in the
  permuted index doesn't seem to provide enough information when you don't
  know exactly what you're looking for.  There needs to be more tutorial-style
  documentation, particularly in the area of system management.

Management/Administration:
  There need to more and higher-quality tools for the management and
  administration of systems.  The system needs to be better instrumented to
  support this kind of thing.  [I'd hate to say this, but one of the distinct
  advantages of VMS over UNIX is it's substantially better instrumentation].
  It ought to be trivial, for example, to discover who has what files
  open (by name);  UNIX currently provides no such facility (or an only
  partially functional facility).

Kernel:
  Whatever mods are required to support any of the above-mentioned stuff.
  Restrict filenames to alphabetics,numbers,and punctuation, keeping in
  mind national character sets.  The basic notion is that it ought to be
  impossible to create a filename you can't trivially remove/display.  I'd
  further distance the I/O system (drivers, etc) from the main part of the
  kernel, mostly for robustness--it ought to be difficult for a malfunctioning
  piece of non-critical hardware to take the system down or wedge a user
  process.  I'd make device drivers dynamically loadable.  I'd re-arrange
  the kernel so that more of it is dynamically tunable, and provide an
  interface to inspect and modify dynamically-tunable kernel parameters.
  I'd make a sweep of the I/O system to generalize non-blocking I/O, and
  make sure it WORKS in all the places you'd expect it to work.  I'd probably
  make select() available.  I'd probably make shared-memory available, but
  I'm not sure how wonderful the shm*() calls are.  TCP/IP networking is a
  must--it should be tunable at run-time (I'd like to see the KA9Q code in
  the kernel, with some performance enhancements).  I'd probably modernize
  the overall kernel structure.  I'd generalize the filesystem code to make
  it trivial to support all kinds of filesystems (a la the filesystem switch).
  It ought to be possible, for example, to mount an ANSI-labelled tape, and
  have it appear as a collection of files on a mount-point; restrictions would
  obviously apply.  Security should be improved by reducing the "granularity"
  of priviledge.  That is, priviledged operations currently all require that
  you are "root".  Perhaps there ought to be VMS-style privilege bits, or
  perhaps just a reorganization of the kernel to allow various UIDs with
  increasing levels of privilege.  VMS has too many privilege bits, UNIX has
  too few.  There ought to be shared-libraries--they save disk-space, if
  nothing else.  The number of "panic" conditions should be reduced--if
  a situation can economically be recovered from without crashing the system,
  it should be recovered from.  When a I/O error occurs during swap,
  for example, the bad-blocks should be marked, and the affected process
  terminated.

Miscellaneous other stuff:
  The current TTY driver should be trashed and re-written.  It almost certainly
  qualifies as the most over-worked piece of code in the system.  The notion
  of CLISTs should certainly be re-visited, and probably abandoned.  The driver
  should have hooks to support windowing systems easily.  Flow control should
  be bullet-proofed (in particular, TANDEM should work properly in both
  RAW and COOKED modes).  I like the VMS-style echo-at-read-time echoing.
  It should probably be a configurable option.  The tty-driver needs the
  following characters (configurable, of course):
    - Kill line
    - Kill character
    - Re-display current input line
    - Flush type-ahead
    - History-next
    - History-previous
  The "History" characters should do something (post an interrupt?) that
  causes the current command interpreter to place appropriate history into
  the tty driver input buffer. Some other mechanism may suggest itself.
  The filesystem layout should be redone to reduce complexity and confusion
  Currently, there are executable files sprayed all over the filesystem
  with no or very little reasonable justification. It ought to be easier to
  find stuff when you go looking for it.  There ought to be a "resource"
  allocator that is responsible for allocating peripherals to users.
  The current ad-hoc schemes used by cu and uucp, for example, should be
  changed to use the "resource allocator".  Modems,tapedrives, and special-
  purpose output devices come to mind as objects that could reasonably be
  under the control of a "resource allocator".


Just in case anyone is under the impression that I'm a VMS-lover, I'd like to
  say that in general I detest it.  There are specific ideas in VMS
  that I think UNIX could adopt without suffering significant conceptual
  damage.
-- 
"Better Living through modern chemistry" PaperMail: 130 Colonnade Rd, Nepean,ON
Marcus Leech                             E-mail:     ml@gandalf.UUCP
Gandalf Data Ltd                         PacketRadio: VE3MDL@VE3JF
"The opinions expressed herein are solely my own" So there