|
Questions and Answers on Bochs with Kevin Lawton
Copyright © 1999 Rezidew
- Who/What inspired Bochs?
- Mostly a what. Over the years of being a programmer and
systems administrator, I was frustrated by having to maintain
multiple systems to achieve what should be capable on one
machine. Often, people would have one workstation for
serious computing, and one PC to run their Office like
programs. I saw that it would invaluable to run everything
on one machine, even if it were not of the same architecture.
Since I had some background in compiler design and a mind
for reverse engineering software, I thought I'd give writing
a PC emulator a spin. Hey, how hard could it be? :^)
- How is bochs different from other emulators like DOSEMU, WINE, and
VMWare?
- This is a commonly asked question, and a good one. Bochs is
a pure emulator, in that it emulates everything: the CPU,
IO devices, memory, etc. It's easiest to think about
DOSEMU and Wine as API emulators. Though, it's a little
more complicated than this, they run things natively and
trap the API calls and re-map them to native X11/Unix. Thus
this kind of emulation is bound to running programs oriented
towards a particular OS; DOS and Windows in this case.
VMWare (and my new project freemware) use virtualization technology.
In short, things are run natively, and the virtual machine
monitor sets things up so that accesses to features which
would otherwise make it impossible to run multiple operating systems
concurrently trap out and are emulated or handled intelligently.
- Virtualization works at a lower level than does an API emulator,
and it works independent of the OS that is being run inside it.
Some features do need to be emulated. For instance, the
IO devices such as the hard drive, video card, keyboard etc,
need to be emulated, since they are not designed to be accessed
by multiple operating systems concurrently. Most code, however
can be run natively. Thus this is a hybrid technique somewhere
between running the OS and applications natively and running
them in a pure emulator. Fortunately, emulation of the IO
devices is also done in bochs, and it is this code which I'm
moving over to the open source domain to be used in freemware.
- You have mentioned Freemware a few times. How will
the code produced from this project be different
from bochs? Will Freemware suffer the same limited
Host and Guest OS options as VMware?
- Freemware will use virtualization techniques, much like
VMware, so it'll run most code natively. Bochs emulates
everything. Also, freemware is purely an open-source project.
The commonality will be the emulation of IO devices. Hopefully,
we will be able to maintain a common set between freemware
and bochs.
- A goal of freemware should be for it to run on any capable
host x86 OS. I will stress modularity throughout the
project development. Which host operating systems are actually
supported will likely be limited to which ones people are
interested in porting freemware to. As far as guest OS's go,
the hardware feature set used will determine what and when a
guest OS is supported. We'll try our best to support them all.
- How long, before there is any executable code from freemware?
- Depends on the volunteerism and support. Lot's of people
have pledged their support. As long as the momentum keeps up
this should not be a problem. Commercial backing will help too.
Certain expensive tools such as an x86 ICE would help.
A couple of the volunteers have worked on virtualization projects
to some degree, and that can't hurt. At any rate, I'd like to
have something functioning by the end of 1999.
- The freemware project has forced me to learn about
Linux kernel device driver development. I'm reading up
on that now, and will learn more about the kernel soon after.
Not a bad thing to know about...
- Why the decision to provide full source code to bochs, but retain
a commercial license?
- With some projects, an open source license works great.
But the thing about PC emulation, is that damn near every piece
of it is poorly documented or not documented at all, and much is
badly designed. It has taken every thing I had, to get this project
working; continuous late nights, and sacrifice in just about
every category. Not to mention the pile of money that went
into resources and living expenses while I did nothing but
work on bochs. Being able to obtain special commercial
licenses has been critical to the survival of this project,
and at the point when it pays me back, bochs will then be
open source. People on the developer's list have been really
understanding of this. The time will come...
- You asked why provide full source. I like the idea of
a completely open project. The feedback and expertise
out there is incredible. And because of the open-ness of
the project, I've bumped into a number of interesting
projects and people I wouldn't have otherwise.
- Freemware will be completely open-source but will it be GPL'd?
- So far, consensus is that it will be LGPL. Some other open
source projects have expressed interest in using freemware
with their code, so LGPL makes more sense. Nothing is set
in stone yet. We're working out implementation ideas at
the moment. I'll take a vote when we get to coding, which
will start soon, as there are some smaller pieces we can
begin work on almost immediately.
- How does bochs get paid for?
- Mostly by special licensing and consulting agreements I work
out relating to bochs and emulation. Though, I'd love if some
company would endow me with a reasonable sum, so that
I didn't have to detour every now and then in order to
support this effort. :^)
- What is Dynamic Translation? & Why the decision to add it?
- This is a method of accelerating emulation by converting
user code x86 code sequences to code sequences which will run on
the native architecture, on the fly. After a code sequence has
been translated, the next time the execution path reaches
that point, the translated code is run, rather than interpreting
it. The rationale behind adding dynamic translation is simply
based on performance. This is certainly the most challenging
software task I've ever worked on. The x86 processor is not
a very clean architecture, and it is very complicated to
translate code to something which is both efficient, and
carries out all the necessary checks which are done implicitly
by the CPU hardware.
- Does it affect the 'portability' of Bochs?
- Dynamic translation is a configurable compile time option,
so bochs retains it's portability. But for each platform to enjoy
the performance gain of dynamic translation, a CPU specific
back-end needs to be written.
- How important is portability in bochs?
- It's very important to me. I want bochs to run on every
capable platform, and be efficiently ported to new ones.
One of the main goals here, is for people to choose the
workstation they want based on it's quality, not what
software is available for it.
- What's the ultimate Goal for BOCHS?
- I'd like to see Windows running at a comfortable speed on
a reasonably powered Linux workstation, using dynamic translation.
- Do you not feel that you are trying to hit a moving target? Being
that new processors are coming out every 8 months. In addition M$
is making every new version of windows suck more and more of the
system resources for their 'features'.
- I do feel that way sometimes. But, nobody said it'd be
easy. As far as Windows gobbling up more and more resources,
this would provide a further push for freemware, which will
run Windows much faster than bochs. Though, this solution
only works on a PC.
- Do you think bochs will ever be shrink-wrapped and put on a shelf
For the general public to purchase?
- Some day perhaps I'll offer binaries. Things are still too
developmental for me to think about that.
- I have heard recently that M.E.S.S. added emulation of the 8088, and
VMware was announced not that long ago, do you sense a trend here in PC
emulation software for the PC platform?
- I sense the biggest trend is in running Windows software on
Unix machines. Linux is really making inroads, but there's
lots of legacy software out there that people have shelled
out a lot of cash for, or are locked into using. What makes
moving to Linux feasible, is the ability to run all the
software they have invested in.
- Since the x86 platform doesn't seem to be going away, it's
important to offer a solution which works as efficiently
as possible for running one x86 OS on top of another. For this,
the virtualization technique offers the highest performance.
This is the impetus behind the freemware project, which is
a completely open source initiative.
- For non-x86 platforms, dynamic translation yields the best
performance, as virtualization requires the same host and
guest operating system architectures.
- Some people feel that, Linus Torvalds would not have been able to
produce the Linux Kernel, if not for the work done by Andrew
Tannenbaum with Minix. Is there any project or person to which you
attribute the general existence of bochs?
- I didn't base bochs on any prior work, though there were
a couple major factors which made bochs possible,
and still are major players. First, the availability of
all the GNU software and the Linux kernel gave me a great
development platform. Second, I've received feedback and
help from many people. Certainly, we all walk down paths
paved by others. Hopefully, we can lay down another 10 feet
or so; that much closer to where ever we're trying to go.
- Some day soon people will occasionally fire up freemware or bochs
to run some legacy software, not even thinking about what went
into these projects. And as a result, they will be able to
accomplish more and move on to the next step. That's how it
should be.
- There is a copy of bochs that accompanies Andrew Tannenbaum's book
"Operating Systems Design and Implementation". How did this come
about?
- Since his OS software wasn't ported to all platforms, he wanted
to include bochs on the CD so people with non-x86 workstations
could still use it, running it inside of bochs.
- Do you prefer "Emulator" or "simulator"? Andrew [Tannenbaum] always
refers to bochs as a the latter.
- I prefer "emulator", but I suppose it's all a matter of
perspective. There's a lot of grey area between all
the various technologies. Given I learned from Tannenbaum's books
in my classes at college, I think "simulator" is acceptable
too. :^)
- Do you feel at all stigmatized by the use of the word 'emulator',
considering all the controversy surrounding console emulators such
as UltraHLE, Bleem and Virtual Game Station?
- No problem here with the word "emulator". I use it all
the time. I've been following the Bleem and Connectix VGS
stories a little. These cases will set a precedence which
by nature, I'm very interested in.
- What's next after bochs and freemware?
- Well, in my mind CPU architecture is not what it should be.
Tremendous increases have been realized in raw clock speeds,
and in instructions per clock. But most modern processors
are still plays on the standard single thread fetch-decode-execute
architecture. I had some ideas years ago before I started
bochs, on a completely new CPU architecture. Also, I think it'd
be cool to have a computer with a programmable CPU core, such
that you could download a new version of it's logic whenever
you wanted, from your Linux cross compilation environment.
And of course, Linux would be the first OS ported to it. :^)
- The "GNU Open Processor". Yes, I can see it now. One moment
you download an x86 core, the next a PPC, the next our own
new architecture. Or perhaps have one high-performance sub-core,
then run processor specific personalities on top. Damn, that'd
make virtualization and emulation much easier!
|
|
