Path: utzoo!attcan!uunet!husc6!bloom-beacon!usc!orion.cf.uci.edu!uci-ics!zardoz!everex!mb From: mb@everex.UUCP ( OS Group) Newsgroups: comp.unix.wizards Subject: Re: New (GNU) kernels--what I think Keywords: UNIX progress; controversy Message-ID: <571@everex.UUCP> Date: 1 Jun 89 01:20:35 GMT References: <2501@gandalf.UUCP> Reply-To: mb@everex.UUCP (Michael Burg - OS Group) Organization: Everex Systems Inc., Los Alamitos, CA Lines: 87 In article <2501@gandalf.UUCP> ml@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