gregg%a.cs.okstate.edu@csnet-relay.arpa (Gregg Wonderly) (04/15/86)
The biggest problem with windowing seems to be the lack of knowledge
that the kernel has about the users environment. It seems that several
people have essentially indicated that a more generic communications means
should exist between the kernel and the users terminal.
It seems most natural to develope some sort of protocol for the kernel,
and have much smarter terminals to decipher it. A protocol including info
about the process doing the I/O, as well as other data would be needed.
This gives rise to the question of terminal type. This provides quite
a few problems because EVERYBODY would want to define their own protocol.
I have seen a SUN workstation, and imagine that something of this nature
is used there. Picking a very flexible workstation as a terminal is the
logical choice.
I would like to have some information on systems doing this type of
system/user communication. Please limit yourselves to multiuser systems,
as this is where the issue resides. A single user micro can be as elegant
as you desire, because there is generally one screen. Areas of interest
would probably include the VAX workstation, the SUN workstation, BLIT's,
and perhaps the ATT 7300/3B1.
I will submit a summary if the responses warrant it. I feel that it
is time to start making some decisions on a standard, more elegant mainframe
environment, and stop all of this "My systems better than yours" crap. If
you think your system is better, than tell me why. Please send your responses
to me instead of posting them here. My net-mail address is given below.
Gregg Wonderly
Department of Computing and Information Sciences
Oklahoma State University
UUCP: {cbosgd, ea, ihnp4, isucs1, mcvax, uokvax}!okstate!gregg
ARPA: gregg%okstate.csnet@CSNET-RELAY.ARPA
or
ARPA: gregg@A.CS.OKSTATE.EDUpdg@ihdev.UUCP (P. D. Guthrie) (04/16/86)
In article <2644@brl-smoke.ARPA> gregg%a.cs.okstate.edu@csnet-relay.arpa writes: > The biggest problem with windowing seems to be the lack of knowledge >that the kernel has about the users environment. It seems that several >people have essentially indicated that a more generic communications means >should exist between the kernel and the users terminal. > > It seems most natural to develope some sort of protocol for the kernel, >and have much smarter terminals to decipher it. A protocol including info >about the process doing the I/O, as well as other data would be needed. I often see in this group postings that draw the conclusion that the magic solution to many problems is to put the code in the kernel. This simply is not so. The beauty of UNIX (I alreay here a lot of groans and "no, not another programming-as-art nut") is that the kernel contains the minimum ammount of code to do what a good operating system should do ; "Hardware provides `raw computing power'. Operating systems make this power conveniently available to users." (Operating Systems, Harvey M. Deitel). Unix provides a set of low level OS interfaces (system calls) to allow the writing of system and applications software. The question here should be, "Does Unix provide the necessary facilities to create windowing software?". If I was asked this about other operating systems (Pick, HP3000-MPE) I would have to say `no', but as it has been shown, to various degrees between the versions, UNIX *does* provide adequate, and in the case of Version 8 (which I have not used, only read about) very good, facilities for windowing systems. I am not opposed to the idea above, rather generically opposed to the idea of solving *applications* problems in the kernel. Version 8 seems to provide a very good alternative with the streams package. You say that the `biggest problem with windowing seems to be the lack of knowledge that the kernel has about the users environment'. This simply is not a problem, but rather a benefit. By providing a virtual (and generic) interface in the kernel, the layers of applications above can be provided by the proper level of control, the user (applications) software. This way the kernel does not have to be tailored to meet specific requirements. Also, to see how difficult your suggestion would be to implement, ask anyone who has had to implement a tricky device driver (tailoring protocols would probably be more difficult) on a *single* Unix machine - it is *very* time consuming with the amount of time spent recompiling the kernel and rebooting. > > This gives rise to the question of terminal type. This provides quite >a few problems because EVERYBODY would want to define their own protocol. >I have seen a SUN workstation, and imagine that something of this nature >is used there. Picking a very flexible workstation as a terminal is the >logical choice. > You have hit the major problem with your scheme on the nose. If everyone did define their own protocol at the kernel level the size and complexity of the code would greatly increase and we have to be Hahvahd grads to know what would happen to the speed. Why should the user on a non-windowing terminal suffer a degradation of performance for this? You suggest picking a `flexible workstation'. If a workstation can be made flexible enough to comprehend many (and often changing - so therefor user definable) protocols, then it should not be so hard to instead have a workstation that interprets non-kernel signals (ie multiplexed output and input, and new downloaded software and administrative commands) from a user process. It's more or less the same thing, so why implement it at such a low level? -- Paul Guthrie `When the going gets weird, ihnp4!ihdev!pdg The weird turn pro' - H. Thompson