> I see no reason why a virtual serial connection between vm's can't be > created.
The main reason is because the amount of overhead involved in implementing a byte-oriented processing paradigm on a block transfer oriented piece of hardware is known to be prohibitive. Other operating systems have tried it and failed due to this problem (AIX/370 is a good example). Everything you've asked for relies almost entirely on inexpensive single-character, byte-oriented I/O. There are *no* byte-oriented devices in the zSeries architecture -- all the things that ever did serial I/O on these boxes did it with outboard front-ends actually doing the serial port management and assembling entire lines to send to the host system -- the host CPU never ever saw the individual keystrokes. You could poll for characters, but that would be unbelievably expensive in processor time, which you don't have much of in the first place. There are things that provide a bit path, like IUCV or APPC, but they are also block-oriented and require lockstep send/receive processing, which leads back to the overhead argument. There are CTC and IUCV-based drivers for network access which leverage the packet nature of network I/O by doing an I/O to transfer a whole frame or network segment, so this doesn't look so bad -- but at that point, you're just as well to get the network working. This is exactly why network access is so critical to Linux on Z; you'd eat the machine alive if you tried to do I/O for individual bytes. The CTC driver for network access relies on a pair of CTCs to basically emulate a SLIP link over a null-modem cable, plus the physical link startup processing to decide who's master and who's slave. We used to have enormous problems with configuring networking because you had to cross-connect the CTCs and keep track of that to get things to work. > But there has to be a way, and if there isn't, IBM > should create a way. The Integrated ASCII Console feature of the HMC is basically that attempt. It doesn't scale very well, and it doesn't virtualize at all. You can get to it by connecting to the HMC over the network, but that opens up a whole 'nother can of worms wrt to access control, etc. > Virtual serial connections can be useful for a lot > more than just consoles. Positing the console problem as a known issue, I guess I'm not following what else you would propose to do with them that couldn't be handled by network-based connections or by the existing IUCV driver talking to the CP *MSG service. If you want to connect to serial ports on external boxes, you can connect to external terminal servers as reverse milking machines via network connections or LAT, and if you want to connect between guests, you can use a network connection just as easily (and then the same technique works inside and outside the box). There is already a LAT client and server if you want to attach terminals to specific applications w/o using telnet. If you just want to log console output, you can already use SCIF and PROP to handle that. Could you toss out some examples? I'm just not understanding, which is why I think we're asking you all these questions. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
