Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
BSD Operating Systems News

plex86 ported to NetBSD/i386 41

Posted by Nik from the they-should-call-it-multiplex dept.
hubertf writes "plex86 is now works on a second Open Source operating system. So far plex86 only supported Linux as host platform, and thanks to Frank van der Linden of Wasabi Systems, it now also works on the i386 port of the NetBSD multi-platform operating system. Tested operating systems include FreeDOS beta 4, MS-DOS 6.22, Red Hat 6 Linux and NetBSD 1.5. See the NetBSD site for more information.
This discussion has been archived. No new comments can be posted.

plex86 ported to NetBSD/i386 More

plex86 ported to NetBSD/i386

Comments Filter:
  • How hard would it be to port this to Darwin (and subsequently Mac OS X) on either Mac or Intel hardware? From what I have seen, programs that operate on a BSD variant have been quickly ported over, can the same be done here? Art

  • Re:Trend in free software.... (Score:3)

    by Baki ( 72515 ) on Thursday December 14, 2000 @04:06AM (#560148)
    Any decently written application for a UNIX variant (including Linux here) should run with very little effort on any UNIX variant.

    Alas there are more and more bad programs that use Linux peculiarities, making the port unnecessary hard (and thus sinning against the common UNIX philosophy).

    The longer a program is isolated on one UNIX variant, the bigger chances are that it will be hard to port afterwards, that it will rely upon non-standard API's i.e. bad design. Thus it is good for the program to be ported ASAP.
  • Okay, i'm just thinking of a kernel level emulator... Just emulate the processor. For the sake of thing like closed source drivers. And for binary apps, like WordPerfect, Oracle, ColdFusion, WebTrends, etc...

    I think it's impossible to ask that every vendor release the source to all their applications or even provide precompiled binaries for every possible platform their program could run under. Including an x86 emulator in the kernel could open up a world of programs to users.

    Developers intent on continuing to use C, C++ to deliver their applications could do so and still reach a sizable audience, whereas vendors could also use Java as a more "forward looking" solution, except aside from the backend, enterprise machines, Java's largely missed it's original mark of being a common API across all platforms.
  • Plex86 sorta absorbed the Bochs Development team. IIRC, there is some bocbs code in plex86. Bochs is a x86 emulator that seems to work on PPC Mac's (which a lot of coaxing/hacking/etc.) How difficult would it be to put a bochs emulationl ayer under the whole thing?
  • A kernel-level x86 emulator would only do one thing, really. It would allow people running Linux on Macs and Alphas to also run Linux applications that were compiled for Intel systems. And at a much slower speed.

    Closed source drivers are not an issue, because most hardware is architechture-specific. Meaning that a driver for my PC's TV-tuner card would not be much use in my Apple G4, because my TV-tuner card won't work in my G4. Or my soundcard, or my videocard, or my modem. So there's no point in emulating the driver on a different system, because the hardware can't be used anyway.

    So now we're written an entire processor emulator (x86 only) so that the very small minority of people that are using Linux on alternative hardware will be able to run WordPerfect? The majority of closed-source Linux applications that most people would want to run, are games. And games are very performance sensitive, so they don't take well to being emulated; a task that's guaranteed to kill your speed.

    It's just not really a very useful feature to have.

  • If I remember correctly beos does some funky stuff with ring3 code so itl'l be a while before a complete port of plex86 to beos is done.
  • I guess that means there is only a few people using for each architecture it is available on. Thats all it would take to make this troll's numbers.

    I've never posted to Usenet so I guess my vote doesn't count. I suppose that's ok because I'd vote multiple times anyway. If you want to talk about OS you use then I vote for OpenBSD, FreeBSD, NetBSD, 4 or 5 Linux's, Beos, QNX, Atheos, etc.

  • Yes but no.

    Errm. I am referring to "Thus it is good for the program to be ported ASAP."

    plex86 is a very complex piece of code, mostly because of the presence of a linux kernel module that plays tricks to do the virtualisation.

    In presence of such code, early port can put an unecessary burden on the project, because it 'freezes' the avalaible options (unless they want to break the NetBSD port, which can cost developers). OTOH, it can have a very benefit effect by showing at early stages of development what are linux kludges, and what are not.

    Btw, I am extremely impressed here. I wouldn't have bet anything on a BSD port. (Now, if someone could port it to FreeBSD...)

    Cheers,

    --fred
  • What'd be really nice, IMO, is if Bochs were somehow implemented as a kernel module for non x86 CPU's... wonder if that's at all doable?
  • So does this make a FreeBSD port any easier? Or have the BSDs moved so far apart that porting it to one BSD doesn't really help the others any?

  • Re:What about Darwin? (Score:3)

    by maggard ( 5579 ) <michael@michaelmaggard.com> on Thursday December 14, 2000 @05:56AM (#560157) Homepage Journal
    Er - things are getting a bit jumbled here...

    Darwin is the core of Apple's Mac OS X but it's Open Source, BSD-compatible & runs on x86 as well as PowerPC. Indeed Apple has made special effort to release Darwin for x86, it's not just by happenstance.

    Thus the original very cogent point that Plex86 could be ported to Darwin running on x86. No where was mentioned MacOS X or PowerPC (though they've been brought up many times in other places recently.)

    I agree that this would indeed be very interesting, if only for the surrealism.

    Who could have predicted 5 years ago that Jobs would return to Apple, have a coup & take over the company, then have Apple buy Next, Open Source the core of their OS, build in BSD-compatibility, make it backwards-compatible with the notoriously idiosyncratic MacOS then release it. To then put an emultor on top of this whole series of suprises would be frosting*.

    Please folks, before you invest the effort into posting please read what the original poster says & not what you guessed from a quick scan.

    * Yes there's VirtualPC etc. but they're MacOS-only and just not as neat as Plex86 though they're arguably more stable & more polished, as well as technically much more sophisticated.

  • plex86, by design, won't work on a non-x86 platform : it isn't an emulator, as Bochs [bochs.com], but a virtualizer. This means most instructions are natively executed, and only privileged ones (as those used by OSes to control processes, hardware..) are trapped and emulated in such a way that no OS can see the others.

    This accounts for its performances, but limits its portability...

  • It will help other ports as well (not just FreeBSD and BSDi, but OSes like BeOS as well).

    The hardest part of porting something as complex as Plex86 to a different OS is figuring out where to start. Just comparing the kernel modules for Linux and NetBSD will teach you a wealth of knowledge, and for the small but important details in the non-kernel bits, grepping for __NetBSD__ tells you where to start your port. After that, it is a small issue of coding and debugging.

    It's not just about more eyeballs or exposing bugs in the primary development platform, it's also about lowering the barrier for other ports, which can accelerate the eyeballs effect.

  • What about Darwin? (Score:3)

    by levendis ( 67993 ) on Thursday December 14, 2000 @03:08AM (#560160) Homepage
    I would love to see plex86, bochs, or even VMware support Apple's Intel version of Darwin (aka OS X). I haven't been able to get it running on any CPU emulators or physical machines. It seems to me that these emulators would find quite a niche in the OS development market.

    Can anybody explain, exactly, why some OS/emulator combinations don't work? I assume it has to do with unsupported hardware (i.e. Darwin only work with Intel PIIX IDE controllers, and maybe all the emulators emulate a VIA controller)
  • Normally porting any code to a different platform helps getting rid of platform specific bugs. This time it's "just" a different OS but it still helps Plex86 and NetBSD.

    And I want to test running NetBSD-1.5 inside Plex86 running on NetBSD-1.5:)

    This is muchos cool!

  • Degrees of porting difficulty (Score:3)

    by DickBreath ( 207180 ) on Thursday December 14, 2000 @04:31AM (#560162) Homepage
    The classic "hello world" program in C can be ported to any OS. (Mac, Windows, etc.)

    I generally agree with your remark about unix software being easily ported to other unix-alikes. At least for user-space things. For the most part.

    Kernel space things may be much more difficult to port. You may be dealing with totally different API's. Or even different concepts, for an extreme example, such as kernel loadable modules, vs. VXD's, vs. Mac OS "Extensions", etc. (Using the term "kernel space" very loosly here.)

    A bad program may, as you say, be unnecessarily be difficult to port. But a program difficult to port is not necessarily bad.

    The question that has not been asked here is: how much of Plex86 is user-space? Doesn't it involve some Kernel trickery in order to achieve the virtualization? I got that impression from Kevin Lawton's paper here: http://www.plex86.org/research/paper.txt [plex86.org]

  • Porting this to NetBSD really isn't the same as porting to Windows or BeOS. BSDs and Linux share a very similar programming interface, most software can be ported between Linux and the BSDS without too much extra work, and in the long run probably keeps code that may be very linux dependent from being introduced. The biggest effort in porting Plex86 was probably the kernel module, the rest probably just needs to be adjusted to not make use of a few linux specifics.

    In the long run, a small outlay of effort porting to NetBSD gains more developers who could work on Plex86. A port to FreeBSD would also be a very good thing.
    treke

  • The NetBSD kernel modules [plex86.org] are LGPLed - does this mean plex86 support will never be a standard part of the NetBSD kernel?
  • It won't be part of a standard NetBSD kernel, but that's not needed. plex86 works just fine as a seperate kernel module, there's no need to integrate it into the kernel.
  • Plex86 is a virtualization system, not a full emulation system (or at least it contains an emulation system, but the point is virtualization.)

    The point of this is that instructions do not have to be emulated because an x86 instruction on FreeBSD, say, is the same machine code instruction on Windows. It's the APIs that are different. So rather than emulating hardware, Plex86 "passes-through" the machine instructions to the hardware unchanged, achieving very low drag on performance.

    So what you want is Bochs, pure and simple. I do hope that Bochs development doesn't permanently stall now that it's creator is working on Plex86. It's a good product, and frankly, I'd love to run x86 apps on OpenBSD on an Alpha. ;)

    VMWare will almost certainly port their stuff to the MacOSX, though probably not Darwin. I'll bet that Bochs is ported to Darwin soon, as it runs on three other BSD's
  • Well, I don't think you really have to worry. After all Kevin is the guy behind Bochs, right (ported to a wide range of platforms).
  • Okay so it boots, but is it usuable yet? Is it in a state where the mouse can be used in an X session or in a windows session? Lets face it not to many people use DOS a whole lot these days. Sure it maybe used for installing windows or something, but how many people are still running DOS as part of there every day life. And I am not talking about opening up a command prompt in windows, but actually starting your computer in DOS and then doing everything in DOS.

    I don't want a lot, I just want it all!
    Flame away, I have a hose!

  • The person who did the NetBSD work, isn't part of the team responsible for plex86, so the work goes on in parallel, and doesn't impact the development of the main product.

    Unlike a commercial software shop, doing the NetBSD port doesn't take away any resources from the main development path.

    And as it has been pointed out many times, the more eyes working on a project, and sharing the results makes for faster and better development.
  • very often bugs in the allegedly "portable" parts of system are uncovered during the porting effort. it also increases the "critical mass" of users for a particular system..
  • Is anyone working on the BeOS port of Plex86?
  • First of all, Bochs is not exactly a superb emulator, but even if it was, why would having it as a kernel module be any better than running it as an application? Except that, as a kernel module, it's conceivable that it could bring your whole system down.
  • I would think that it'd make it easier for people to distribute x86 binaries to users of other platforms. Build in an x86 emulator, and then the end user of a MIPS, Alpha, or ARM machine can draw benefit from the world of precompiled binaries... A lot of programs spend enough time waiting that recompiling wouldn't really be much of an issue.

    It could also lead to accelerated developement of "proprietary" drivers for all sorts of non-x86 PC's.

    Am I wrong in these assumptions? Or do they just need to be fleshed out some more?
  • Having the kernel emulate another processor is not a horrible idea. Having the kernel use Bochs to do this is a very silly idea. Bochs doesn't just emulate the processor, it also emulates devices like the video card, and the hard drive, and the mouse, creating a wholely enclosed system. That means you have to install an operating system to run on Bochs, and allocate a file to act as hard disk space, and all sorts of other issues.

    Implemented the way you describe, a kernel-level emulator could only allow binaries to be run on the same sort of system, with a different processor. So my x86 Linux binaries could be made to run on my Alpha Linux box. Where's the advantage there? It wouldn't let me run Windows applications on my Alpha, unless I installed Windows into the Boch's virtual hard drive. And that's no better than just running Bochs as a regular application.

  • I've noticed a new trend in free software, it appears that there's a concentration on porting all new software to every possible platform before said software is anywhere near completetion. Don't get my wrong, plex86 is _very_ cool. But shouldn't they work on irony out all of the bugs on one OS before porting it to others?
  • But shouldn't they work on irony out all of the bugs on one OS before porting it to others?

    Couldn't have said it better.

  • ... but if you spread it to all OSes, then more people can work on the bugs for their OS...

    In my experience, it has always been easier to get it running on other platforms early in the game... it helps boost spirts. (read: seems like you got something done)

    Later.
  • I've seen an Amiga emulator running an Amiga emulator on Windows. Tres cool.
  • I downloaded this weeks ago, I still got some problems getting it working. But I'm still hoping. I think this is a great alternative for VMWare anyway. Guess it's very good that slashdot now gives some attention to plex.

  • I mean, come on, this is like the third or fourth story in as many days! Or at least it seems like. Can we have a plex86 section to put these in?

  • Re-read the information on the Plex86 [plex86.org] site.

    What you wish for is not relevant as Plex86 is a virtualization, not emulation of the x86 platform. It is not intended to run on any other architecture, as that would be emulation, not virtualization.
  • But is it ported to NetBSD/Dreamcast?

  • Re:What about Darwin? (Score:3)

    by levendis ( 67993 ) on Thursday December 14, 2000 @03:56AM (#560183) Homepage
    Right, but plex86 still has to virtualize the peripheral hardware, just not the instructions. For example, if the "guest" OS makes a BIOS INT 13 call, the emulated BIOS inside plex86 is what actually handles the call. I find it kind of odd that none of the emulators handle the right hardware combination to allow Darwin to boot (of course, Darwin is notoriously picky about such things on Intel hardware)
  • http://www.htc.net/~nbehnken/freemware.html [htc.net] would lead me to beleive that BeOS [be.com] works as a host platform as well, or is at least underway. I think that'd be a good thing, as Be's a pretty darned nice workstation OS with stuff that Just Works (not that it'll be replacing my linux server boxes anytime soon)...
  • Try bochs, who will do full CPU emulation.
    plex runs native code, and only intercepts "interresting" calls. -> speed.

    - Hubert
  • VMWare will almost certainly port their stuff to the MacOSX, though probably not Darwin

    What good would that be? VMWare also is a virtualization system, thus on MacOSX, which runs only on PowerPC, you would only be able to run other PowerPC systems (Linux, NetBSD, a second instance of MacOSX).

    Since MacOSX itself already is based on UNIX (FreeBSD) there isn't too much need for that I guess. The main use for VMWare is to run Windows in Linux/FreeBSD (the linux VMWare runs in FreeBSD too), or to run non-Windows inside of Windows.

  • The reason it is important to "port" projects over when there still in development, and far from complete is two fold.

    One -- Once the full version is complete it will be very difficult to start porting it, having to deal with inconsitancies in unixes and other OS's. Not to mention optimizing it for a platform, may have to be done at a lower level, which would be easy if it were built into the tree early, and hard if it were done later (so it might never happen)

    Two -- By forcing yourself to develop cross platform, you run into the limitations of your design and logic sooner, forcing you to fix it. Cheap workarounds get tossed out in favor of better solutions, because cheap workarounds and sloppy hacks are system dependant, and your working cross several platforms. Just look at what a POS Netscape 4.x is (ok so there is nothing better for unix at the moment) under unix, and under macintosh. It was designed for win32 first, and not designed cross platform. The win32 version is great, and I almost never have problems with it, although I cannot say the same for the linux/freebsd/mac versions. Now compare those to QuakeIII. I've never had it crash in windows, or in Linux, or on a macintosh. (I've had numerous QuakeII crashes under linux though) And its fast under all three systems.

    Now nobody reading this here is John Carmack (exept of course for John, if he reads this far down in the posts) so yea, none of us are going to pull it off quite as well, but we can at least try. Come to think of it, its probably the least painfull way we could all improve our own projects.

Slashdot Top Deals

"I am, therefore I am." -- Akira

Close