New (GNU) kernels--what I think

[OS Group]

In article <2501 at gandalf.UUCP> ml at gandalf.UUCP (Marcus Leech) writes:
>
>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.
[Stuff delete about UI's, Documentation and adminstration]
>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.
I don't agree. There needs to be a way to represent language symbols as
found in Oriental langauges and other such like languages. Remeber that these
languages contants a couple hunderd to a couple thousand or  more symbols
and which are represented by 16-bit characters. Currently the only way
to do this is to allow the full range of possibilities with 8-bits/16-bit
characters.
(Is there a better way?)

>  			....				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 like to see  system calls that work in async. You could start up multiple
requests and then wait on selected events or system call to occur/complete.
I believe this is already done in several Unix variants. This would work
well with multi/parallel systems and could provided a good base for real time
support. As far as select() goes, I'd prefer poll() - it's slighty more
dynamic.

>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).
This should have happened ALONG ago. System V could have done a really good
job, since AT&T decided go with a thing called termio but it really didn't
turn out to be anything special. A process should have greater control
over hardware functions (i.e. such as notification when various hardware
line get assert/deasserted). Also have some type of permissions associated
with setting of the line (i.e. have the ablility to restrict certain processes
from issuing 'harmful' ioctl's.)

I think something simular to the Stream Driver for the networking and/or
tty drivers would work well. Since under the concept you can "push" and
"pop" various drivers on to the stream allow for a array of processing
to occur on the data before it's received  by the  user process and 
hardware driver. What would be great is that if you could "push" and "pop"
a User Process on to the stream.


In a filesystem I would like to see better security and auditing. CDC in
their NOS operating system came up with a great (or did they adopt it?)
system call/command called PERMIT. This allows you to "permit" a file to a
selected user with various permissions. Also, the other things that this
OS had was that you can place a file into "semi-private" status and
the system would log each time a process opened the file.


Signals is another thing that should go, or should be rewritten. There
should be a way to "queue" multiple occurances of the same signal to a
process *AND* a way to find out WHERE IT CAME FROM and WHEN IT OCCURED!!!

Process RECOVERY is a must. It seems that almost every
operating system except UNIX has this. There have been thousands of times
I've been logged into a system via modem and have gotten dropped and lossed
everything that I was working on. (Maybe some like a Session Group assigned
per login, Process groups would be a subset of it thus the OS could suspend
a Session Group which would include your background tasks that are running
under different process groups)

I feel that the first few release of the OS should include binary
compability for the machines it will be ported to. Also, some sort
of emulation package/library should be included for those programs
which conform to various "standards" (i.e. POSIX/SVID/SysVR4, etc).



-- 
-------------------------------------------------------------------------------
Mike Burg Everex Systems Inc. 10525 Humbolt Street Los Alamitos, CA 90720
E-Mail: uunet!zardoz!everex!mb	Voice: (213) 493-3749