HP3000-L Archives

December 2001, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Matt Shade <[log in to unmask]>
Reply To:
Matt Shade <[log in to unmask]>
Date:
Sat, 15 Dec 2001 01:41:31 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (28 lines)
I keep seeing "using the linux kernel"........is there any reason why a new
"MPE" kernel can't be written? Or is it just for convenience?

matt (definitely not a kernel writer) shade


> > Finally, some of us dreamers would like to see a new o.s. written
> > around MPE ideas, as an open source project, but using the Linux
> > kernel, perhaps with kernel modifications or leveraging HP's secure
> > Linux kernel.  The hope here is that it would attract MPE vendors
> > and customers to it as it matures over the next five years, but it
> > would take *some* rewriting and recompiling to use it with existing
> > MPE applications.  With MPE source and a good Pascal compiler, this
> > approach could leap ahead a lot faster, but there would still be a
> > lot of work to do, since (as I've been told) MPE is so monolithic
> > the source won't be as much help as if it were more modular.
> >
> > There is a view that all three make sense.  The emulator merges
> > into the api model at some point, particularly if the approach
> > wanted an emulator for running existing MPE binaries.  The new o.s.
> > approach would merge into the MPE api at some point, such as both
> > need an MPE (like) file system for Linux.  It could be an evolutionary
> > thing, except the MPE api and the new o.s. approach needs the freedom
> > to break "pure" backward compatibility that is the MPE tradition.

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

ATOM RSS1 RSS2