> > Better yet, make them PVM clients over the CTC, and map that PVM session > > as /dev/console. Then you get all the cool automation stuff and > > multisession support of PVM as well. > > What kind of terminal are you sitting at? Seems to me if you're starting > at a block-mode device you have problems.
Well, actually not. After doing some digging around and by grace of friends with archives of ancient goodies (thanks, Arty!), the PVM link signon and session establishment protocols are really the only part that implies any structure on the communication. Once the link is active, it essentially boils down to passing data without translation (similar to the way tn3270 works -- negotiate a clean bitpipe, and then send raw 3270 frames back and forth over the connection, interpreting them at the endpoints as needed). PVM doesn't actually care what the data it's passing is, once the session is up and running -- you wouldn't even have to translate it to/from EBCDIC. The proposed console driver modifications would need to initialize the CTC connecting to PVM, initialize the link and signon, and then wrap the I/O to the console into PVM data packets. For completeness (and to keep PVM happy), the modified driver should also shut down the link and sign off properly at system shutdown. It might be a bit jerky due to the packetization of the I/O within the PVM protocols, but it won't be any worse than doing it over a console switch. With some slight adaptation of the way the 7171 provided a way to switch into a "transparent" mode, I think one could get a console stream that would permit what Brandon wants w/o re-engineering the world. What I haven't figured out yet is whether this would require substantial surgery to the client, or whether we'd be better off putting that surgery into a proxy server and doing it all once. The PVM internode protocol is quite sophisticated -- the designers planned very well for doing stuff like this. If we could get a Linux PVM daemon to communicate with PVM, and then do session mapping in that daemon, then we'd be home free without inventing lots of polyhedral wheels. This would also be a convenient way to be able to move the session mapping outside the 390 if we chose the PVM over IP driver as the communication to the console. Another thought is perhaps to use the existing LAT client and daemon as the starting point, since it already has the kind of session mapping code we want, and just rip out all the DECnet code and replace it with stuff to handle the PVM sessions. That could get us there quite quickly, and latd already has the concept of mapping specific terminals to specific applications, which (with a combination of some entries in inetd.conf) could allow 'telnet frontend xxxx' to map to a specific console session with SSL protection, authentication, etc handled in the frontend. ---------------------------------------------------------------------- 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
