Hello All,

It would be very cool to see MPE running as a Xen virtual machine on Linux.
How to do this is something that donna and I have discussed over a glass of
California wine more than once...

My thoughts and discourses... 

- Emulation of the RISC instruction set is vitally important to avoid
reworking a lot of Modcal (enhanced MPE Pascal) and SPL code.

- I would lay down the MPE file system on top of Linux ext3 file system {if
we reach size limitations on a single file system of 8-16tb, then ext4 or
XFS) in the same way the MPE file system exist on top of POSIX today.

	- I don't see why any of the rich file types implemented on MPE
would not operate in the same manor as they do today with the exception of
MSG files and their support for process to process communications.  Again as
I mentioned above, the MPE file system would be implemented on top of the
Linux ext3 file system and we are counting on the emulation of the RISC
instruction set to execute the file system code.

	- With the RISC emulation mode for the Image code, I would expect
that the Image database would operate with the same functionality as it does
today on top of a MPE file system.  It certainly is also possible to
abstract the image calls and point to a Linux distribution data base or a
vendor purchased data base.  Anyone want their MPE application writing to an
Oracle RAC?

- Capture all MPE I/O calls at the highest possible point in the MPE O.S.
code and insert an abstraction layer which translates from MPE to the Xen
Virtual machine I/O abstraction layer.  Expect to say good bye to sysgen,
all I/O devices attached to the server would be linked in the Xen Domain
zero.

	- This provides MPE access for the most part to all existing and
*new* disk, SCSI tape, USB storage, SAN storage, SAN tape libraries/robots,
network iSCSI storage, and other block and character I/O devices recognized
by Linux; maybe even your Cannon camera or your ipod.  One thing interesting
about Linux is old drivers never seem to die...

	- If you require a MPE historic tape device as an example, it is
possible to accomplish this if a converter and/or interface card exists to
this device which will connect from the device to the PCI bus.  Then all you
need is a positive attitude and a Linux driver writing class; not to worry,
there are a lot of open source drivers you can leverage source code from.

- Capture all MPE Network calls at the socket interface replacing MPE's
sockets code, TCP, UDP, NIC drivers, etc. with the Xen Virtual machine
Network abstraction layer.

	- It would be useful to perform triage of the service level MPE
network code and eliminate any ARPA or NS services which are duplicated by
services in Linux or which still use the NETIPC network sockets.

	- Retain network services that touch the MPE file system.  Some
tough decisions exist here, including the decision to keep or discard VT &
DSCOPY.  For DSCOPY and some other NETIPC based services, it would be
necessary to create a NETIPC to BSD sockets abstraction layer if they were
to be kept.  Keep in mind: On Linux unencrypted protocols are un-cool.  VT,
TELNET, DSCOPY and FTP on MPE are all unencrypted protocols.

	- As with abstracting the I/O layer above, abstracting the network
layer will provide huge improvements over the MPE networking functionality
including SSH, 1gE and 10gE NIC's, iSCSI, NIC bonding and all of the other
standard Linux/UNIX networking features.  Expect to say good bye to nmmgr,
most of networking would be configured in the Xen Domain zero.

- The emulation of the MPE console is a big deal.  The concept of a console
is significantly different from MPE to Linux or UNIX where the console
really is only used for system boot/recovery.  My vote would be to perform
triage on the MPE console functionality, implementing Linux style console
logging to a text file and rework the MPE "recall/reply" printer management
and tape management console functionality.  It is probably time for all of
the "operator" commands to be evaluated for similar functionality in Linux
or UNIX and again triage some of the functionality with the perspective of
MPE running in "lights out" data centers.

- The process scheduler should be abstracted to interface to the Linux
process/task scheduler as well as the Linux I/O scheduler and Linux memory
manager.

- The MPE spooler and network spooler should be abstracted to interface to
the Linux cups printing solution.  Hmmm... We probably need an 'hponly'
printer solution to say in harmony with MPE (sorry I couldn't resist and yes
I need you to buy HP printer ink so I can retire some day).

- The DTC terminal I/O would need to be triaged.  There is nothing like the
DTC functionality in Linux that I am aware of.  I have heard of a scary
serial to USB solution.  I have seen several H/W serial to ssh solutions
that could replace most of the DTC terminal functionality and again network
printing is the Linux solution to all of your printing needs. 

- The Job/Session and CI commands functionality is where the beef is.  I
would expect to see a huge amount of effort here to evaluate every MPE
command and parameter, determine how it interfaces to MPE data structures
and determine which are best to emulate and which are best to abstract to a
Linux interface.  There is a lot of SPL and Modcal code here to investigate,
it would appear to me that the smoothest path would be to emulate "all" of
the MPE core O.S. data structures and abstract to Linux at the highest level
necessary to provide the expected functionality and interface to the
hardware.

- POSIX vs. Linux bash shell - not sure what difficulty to expect here.

- I would 'goto' heaven happy if we could port something as useful as debug
and dat with macros to Linux!  I guess at the same time we would need to
convert MPE system aborts to Linux panics and MPE hangs to Linux hangs :(

I guess it is getting late and I could write pages more...  I am sure that
for anyone who is considering the implementation of a MPE emulator, that my
notes above are just a drop in the bucket to the investigation and analysis
that they have already performed.  I am sure smarter people have already
identified smarter solutions than I have expunged above.

I also am sure I got something in the above wrong... Please feel free to
gently correct me :)-<   I hope my input is helpful and not discouraging.

P.S. My Ideals are my own, not necessarily my employers.

Peace,
  James Hofmeister

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *