rgenter@BBN-LABS-B.arpa (Rick Genter) (07/31/86)
Guy Harris writes: > The point is that you *can't* hide the differences. You *have* to choose > one version of "init", for instance. And you either have to choose one > version of UUCP or have the administrator support both. It's not clear that > a 99% solution is enough better than a 97% solution to justify all the extra > gore needed to get that last 2%; the law of diminishing returns takes over. > There ain't no 100% solution. > - -- > Guy Harris > {ihnp4, decvax, seismo, decwrl, ...}!sun!guy > guy@sun.com (or guy@sun.arpa) There is a 100% solution, though as far as I know no one has actually implemented it yet. See my paper "Unix as a Virtual Machine Environment" from the Atlanta Usenix Proceedings. -------- Rick Genter BBN Laboratories Inc. (617) 497-3848 10 Moulton St. 6/512 rgenter@labs-b.bbn.COM (Internet new) Cambridge, MA 02238 rgenter@bbn-labs-b.ARPA (Internet old) linus!rgenter%BBN-LABS-B.ARPA (UUCP) I wonder if I could ever get started in the credit world?
guy@sun.uucp (Guy Harris) (08/01/86)
> There is a 100% solution, though as far as I know no one has actually > implemented it yet. It's not clear handling the S5/4.2 differences by running them as guest operating systems under some hypervisor (whether UNIX or something else) would be a win. For one thing, it's kind of gross to go through all that work to get around differences that are relatively minor. The user would, again, have to manage two sets of administrative utilities; why should they learn about another version of "init" just so that somebody can run a shell script that requires different behavior from "tr"? For another, would "open" be treated as a virtual machine instruction (so that the file system code is part of the hypervisor) or would you provide minidisks to each of the "guest" operating systems? In the latter case, it may be a pain to share file systems; that much partitioning would render this scheme useless. Also, you'd have to partition the terminal ports somehow; either a given terminal port is always assigned to one virtual machine (which loses for dial-up ports) or you'd have to have a command that the hypervisor's handler for ports recognizes, so you can connect to the desired one. The notion of UNIX as a hypervisor is interesting; it's not at all clear that this is an appropriate use for it, though. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
bzs@bu-cs.bu.EDU (Barry Shein) (08/03/86)
Re: Hypervisor, VM, run 'em both at once My, my how things do transpire... We could put up a system like this tomorrow on our IBM 3090, for example putting up Amdahl's UTS and IX/370 under VM simultaneously, I have a little feel for these things from a practical level (we run 3-4 O/S's under our VM.) In theory it's trivial to provide some way to choose which UNIX would get bootstrapped at login (remember, on an IBM one logs into VM which then would proceed to boot the O/S as part of the login process, or you'd have dedicated ports that your MUX [or via distinguished phone hunt groups] have divvied up.) Also note that booting something like UNIX on a good sized [eg 3090] IBM probably takes as long as it takes you to now get through tset etc [20Mips, FAST disk channels etc]. To choose at login you'd probably just login in as 'loginname/ostype' or something obvious like that. Each would have to have its own mini-disks (virtual disk areas) as 4.2 and SYS/V currently use incompatible file system structures. Further this means they could not share (mount) these disks any more than you could mount a removable disk pack from the other system in a conventional setting. If I really had to solve this I think I would look at running NFS over a virtual IPC channel within the machine. Currently these various systems available utilize different terminal hardware on IBMs basically owing to the problem that no IBM tty hardware is suitable for full-duplex ascii terminals, so each developer had to "make it up", Series/1, 4705 with mods etc. This hurts any effort but the obvious solution is to use TCP/IP and something like an Annex box (TCP/IP terminal server). Of course, unless you have a good reason to do all this, this approach is absurd, it would be more cost-effective (well, assuming that most of your users use one system and a few need access to the other) to just buy two boxes, for example I am typing at a SUN3/4.2 right now and I could (and have) just ship any code I thought might need to be tested for SYS/V compatability to the 7300 on my desk here. Those folks who really need to run two APPLICATION environments (eg. the word processor they *must* have only runs under SYS/V and the database they *must* have only runs under 4.x) have worse problems. Personally I would (and have) play systems fascist and tell them to go choose compatible software or get out of my office (I mean, it ain't just SYS/V vs 4.2, they'll pull that BS on you with AOS/VS, IBM/VM and VMS also if you let them start squawking, hell, they can do whatever they like, so long as they don't expect me to clean up the mess later when they're sorry, or burden the extra costs.) What is utterly absurd is the lengths to which people are going for this compatibility, like an animal gnawing off its leg to get out of a trap. Obviously we need one O/S that is a superset of the two, and fast, before this lunacy of dual universes and half our disks being taken up with nearly unnecessary #ifdefs (well, I exaggerate) eats us alive. Of course, when this mythical system hits the market it will cause a period of pain due to certain mutually exclusive semantics of the two systems (eg. a.out formats, signal semantics, some commands) but I at least that changeover might well be the last, so at least it would be worthwhile as an investment. I know, P1003, but so far that's a document not a program, maybe someday, and maybe if it incorporates enough of the parts of each I feel I need. Until then I'll run 4.x (my preference) and try to ignore all the other competitors in general. Reading all these messages I am not sure whether to laugh or cry... -Barry Shein, Boston University