- commit long due "roadmap/todo", from my post and comments in the ml
and the irc chat.
This commit is contained in:
parent
cf1d0d0aaa
commit
af33a50882
309
bochs/TODO
Normal file
309
bochs/TODO
Normal file
@ -0,0 +1,309 @@
|
||||
This is the "roadmap" posted in the mailing list, augmented by
|
||||
comments from the mailing list and the irc chat.
|
||||
Anybody is welcome to work on any of these issues. Some of
|
||||
these items are rather simple and can be implemented by single
|
||||
individuals. Other items are quite complex and development needs
|
||||
to be coordonated. So, if you want to contribute, please drop
|
||||
us a note in the mailing list, so you can get help or exchange
|
||||
ideas.
|
||||
Christophe Bothamy.
|
||||
|
||||
0. Donations
|
||||
Source Forge recently set up a donation system for hosted projects.
|
||||
Should we accept donations ? What could we do with the money ?
|
||||
- give to EFF, FSF or other
|
||||
- fund Kevin to continue the work on plex86 so we can use it
|
||||
- bounties for somebody write optimized win9x/NT/XFree/linux/*BSD
|
||||
drivers for our vga/net/ide cards
|
||||
- other ?
|
||||
|
||||
1. GPL source file in Bochs
|
||||
Daniel Gimpelevich pointed out that rfbproto.h is released
|
||||
under the GPL. This is incompatible with our license, so
|
||||
we need to rewrite/find a replacement this.
|
||||
Also, we should make sure that contributed code / patches
|
||||
are LGPL compatible.
|
||||
|
||||
2. PCI
|
||||
2.1 I'd like to implement a PCI framework, that would take care
|
||||
of handling pci config regs (mmio enables/remaps, port io
|
||||
enables/remaps), offer entry points for the simulated pci chipset
|
||||
(for example pci irq routing), handle embedded bios, and so on.
|
||||
I guess it will also need to take over the ISA I/O and
|
||||
memory management. Ideally, it would be keeping compatibility
|
||||
when pci is not compiled in.
|
||||
(see http://marc.theaimsgroup.com/?l=bochs-dev&m=107165515315420&w=2)
|
||||
2.2 The System BIOS will also be impacted. Although it has
|
||||
basic BIOS32 service directory functions, we will also have to
|
||||
identify and initialize the connected cards, including optional
|
||||
roms (copy to main memory and initialize), and build the correct
|
||||
PIR table in memory.
|
||||
2.3 configuration file for pci
|
||||
It would be nice to have a generic way to set the bus/device numbers
|
||||
of pci devices in the configuration file.
|
||||
2.4 host<->guest pci proxy
|
||||
Being able to use a real pci device from inside Bochs would be a
|
||||
great feature of Bochs. It would ease reverse engineering of non
|
||||
documented cards, or one could even use a real spare vga card.
|
||||
Frank Cornellis has done a great job on this subject, and we began
|
||||
integrating his changes.
|
||||
2.5 existing PCI device will need a slight rework to use the framework
|
||||
|
||||
3. Subdirectories in iodev
|
||||
The iodev directory contains the various implemented iodevice.
|
||||
With the new pci devices, new harddrives and new net access methods,
|
||||
it could be interesting to add new subdirectories like :
|
||||
iodev/video/... --> for standard vga and new card emulation
|
||||
iodev/disks/... --> for the ata/atapi classes, hd/cd classes and host accesses
|
||||
iodev/net/... --> for ne2k and host net access
|
||||
isa and pci devices would be mixed in the directories, but this should
|
||||
be manageable.
|
||||
|
||||
4. Speed
|
||||
Speed (well lack of) is one of the biggest criticism made by users
|
||||
who'd like to see Bochs run as fast as Virtual PC.
|
||||
Paths we can explore to get more speed :
|
||||
4.1 virtualization : plex86
|
||||
4.2 dynamic translation : qemu, patch from h.johansson
|
||||
4.3 optimizations of instructions path / host asm (Conn Clark has been
|
||||
working on this, and an anonymous patch for win32
|
||||
http://sourceforge.net/tracker/index.php?func=detail&aid=867044&group_id=12580&atid=312580
|
||||
)
|
||||
4.4 multithreading. Conn Clark wrote :
|
||||
Threading might be nice too, for those of us who have SMP/SMT machines.
|
||||
I have a patch from Mathis (who hangs out on the IRC channel all the
|
||||
time) that puts the video card interface in its own thread. It has
|
||||
troubles though that I have not resolved. It may also be easier to debug
|
||||
a threaded peripheral.
|
||||
I also think that it might be possible to thread a chunk of the CPU
|
||||
emulation to improve performance on a SMP/SMT machine. Specificaly
|
||||
write_virtual_dword, write_virtual_word, write_virtual_byte, etc...
|
||||
might just be able to be threaded. I think the threading overhead might
|
||||
be less than the protection and address translation code. We would have
|
||||
to try it to find out. I'm also sure there can be some nasty hurdles to
|
||||
overcome.
|
||||
|
||||
5. CPU
|
||||
5.1 This was asked in the ml, and I believe it's a good idea to provide
|
||||
a configure switch to set the cpu model, for example :
|
||||
--with-cpu-386
|
||||
--with-cpu-486dx
|
||||
--with-cpu-pentium
|
||||
--with-cpu-pentium-mmx
|
||||
--with-cpu-k6-iii
|
||||
--with-cpu-amd64
|
||||
and so on. The main difficulty here is to set up the list of features
|
||||
by cpu model. I started such a list, available at
|
||||
http://cbothamy.free.fr/projects/bochs/CPU_Features.sxc
|
||||
The configure script will then set up constants on features to compile in,
|
||||
ISA, FPU, MMX, 3DNOW, SSE, etc... Most of the feature flags already
|
||||
exists in config.h, so this should be easy. It would also be a good
|
||||
idea to clean up the cpuid function beased on those flags.
|
||||
We also have to keep in mind that some features are also enablable
|
||||
by the guest os.
|
||||
Please note the all features are still not supported/complete in Bochs.
|
||||
5.2 Stanislav thinks that configure --with-cpu-pentium-mmx --enable-cpu-level-4
|
||||
would create lots of conflicts in the generated config.h. He suggests
|
||||
that we should write an external GUI configure script that would propose
|
||||
standard or custom cpus and would detect conflicts.
|
||||
|
||||
6. VGA
|
||||
Several thigs we could use to improve SVGA emulation :
|
||||
6.1 framebuffer by Christopher Nelson
|
||||
6.2 S3 emulation in qemu / patch by tld
|
||||
6.3 Look at Trident emulation of dosemu
|
||||
6.4 patch for PCI CirrusLogic CLGD54xx by m-suzu
|
||||
6.5 voodoo3 (specs http://v3tv.sourceforge.net/docs.php )
|
||||
|
||||
7. Random thoughts on disk emulation improvements :
|
||||
7.0 IDE-Busmaster support (needs pci)
|
||||
7.1 lba48 support
|
||||
7.2 >32GiB disks
|
||||
7.3 autodetection of disk size / geometry
|
||||
7.4 uml cow disk image support
|
||||
7.5 compressed disk image support
|
||||
7.6 extend redolog-disk specification to add coherency check of the flat
|
||||
image file, by storing its fstat-mtime field in the redolog.
|
||||
|
||||
8. net
|
||||
8.1 New devices ? are specs available anywhere ?
|
||||
8.2 bootable ethernet rom ?
|
||||
see etherboot, Micheal Brown wrote :
|
||||
This already works; you can build an Etherboot rom image with the pnic
|
||||
driver, specify it as an option ROM in bochsrc and it will boot. I'm
|
||||
using this extensively at the moment in Etherboot development.
|
||||
In the Etherboot project's CVS, in the contrib/bochs directory, you can
|
||||
find a working bochsrc file and an up-to-date README with step-by-step
|
||||
instructions on getting this working.
|
||||
|
||||
9. Bios
|
||||
9.1 our bios is quite heavy on stack space (notably during int13 functions).
|
||||
This should be fixed. A partial patch exists
|
||||
see
|
||||
http://sourceforge.net/tracker/index.php?func=detail&aid=832330&group_id=12580&atid=312580
|
||||
Some parts can be rewritten in assembler, to save stack space and
|
||||
make code smaller.
|
||||
We could define a reserved area in the BIOS where we can fill in PCI and SMP
|
||||
specific data before starting the simulation or during POST. The same could
|
||||
be done in the VGABIOS with the VBE mode list.
|
||||
9.2 with pci and smp support we'll need to include several tables in the bios.
|
||||
We have two possibilities : dynamically build them during POST
|
||||
or statically build a collection of bioses, which can be selected
|
||||
at run time.
|
||||
9.3 add "jump table placeholder" and log missing function calls in the bios.
|
||||
Check completness with Ralf Brown interrupt list.
|
||||
|
||||
10. LGPL VGABios
|
||||
10.1 Stack space
|
||||
As for the system bios, the vgabios is heavy on stack space, and
|
||||
should be fixed. Some parts can be rewritten in assembler, to save
|
||||
stack space and make code smaller. The size of the debug version
|
||||
of the VGABIOS is currently 30k and it will exceed 32k if we
|
||||
fill in some of the unimplemented features.
|
||||
10.2 Video parameters table
|
||||
There is a very nice parameter table in 3dfx banshee document
|
||||
http://www2.lm-sensors.nu/~lm78/pdfs/Banshee_2d_spec.PDF
|
||||
see also http://www.xyzzy.claranet.de/dos/vgacrt.c
|
||||
|
||||
11. Optimized Guest drivers still needed : VGA, IDE, NET
|
||||
We have a specific VGA driver for winNT/2K, but still
|
||||
lack drivers for other OSes.
|
||||
|
||||
12. Plugin architecture
|
||||
12.1 The plugin architecture can be reworked if we want to support
|
||||
multiple similar devices like seral net or vga cards.
|
||||
We currently have two "types" of plugins: "core" and "optional".
|
||||
Maybe we could add "classes" of plugins. The current version of
|
||||
Bochs supports the classes "display_library" and "io_device".
|
||||
New classes can be "config_interface", "net_lowlevel" and
|
||||
"sound_lowlevel"
|
||||
12.2 Stanislav wrote :
|
||||
Plugin architecture should be rewritten like real plugin architecture s.t.
|
||||
Bochs VGA plugin for example will be real plugin. I mean that replacement
|
||||
of plugin dll in already compiled Bochs will replace Bochs VGA card and
|
||||
the new card will be detected automatically.
|
||||
This will allow for example developing of plugins separately from Bochs.
|
||||
12.3 Michael Brow wrote :
|
||||
If the configuration interface is to be reworked, could we also make it so
|
||||
that plugins are self-contained, rather than needing to pollute main.cc
|
||||
with code for defining and parsing plugin-specific options
|
||||
|
||||
13. Save/Restore
|
||||
We already have a specific branch in the cvs with a save/restore
|
||||
framework. The work still needs to be completed.
|
||||
I guess it would be useful to be able to stop and
|
||||
restart the emulation, or create "checkpoints" to restart the
|
||||
emulation from a known state. We can also give a look on how
|
||||
integrate commitable harddisks with the save/restore strategy.
|
||||
|
||||
14. USB support
|
||||
Ben Lunt has been working on USB support. We should check with him
|
||||
what is the current state of his work and if we can merge his code.
|
||||
How can we add USB device, for example a mouse ?
|
||||
The current version of Bochs supports only a PS/2 mouse. If the
|
||||
USB support is more complete the user should be able to select
|
||||
the mouse type (ps2, serial, usb).
|
||||
Ben Lunt wrote :
|
||||
I have, but it is not complete yet. Currently, my goal and the
|
||||
way it is coded, you simply have to increment the "number of devices"
|
||||
and add a new USB_DEVICE struct. Then you fill in the struct
|
||||
with the values needed for that device: 18 bytes of descriptor, 255
|
||||
bytes of config, strings, interface, etc. One of the members of
|
||||
this struct will be a pointer to a driver for that device.
|
||||
I have two structs filled in. One is a USB mouse. Win98SE, as
|
||||
a guest, recognizes the mouse, but does random movement and
|
||||
clicks. I haven't tracked this down yet.
|
||||
The other device is a USB numpad. Win98SE also detects the
|
||||
USB Composite Device under USB devices, two HID's, and
|
||||
a System Control and User Control device under HID's. However,
|
||||
there is a yellow mark on the HID's. I think it has to do
|
||||
with my config binary data. I am still working on it.
|
||||
However, the USB stack, command phase, data IO phase, and
|
||||
status phase is complete. You can successfully retrieve
|
||||
the descriptor(s) and string(s), and set the devices address.
|
||||
|
||||
15. Patches / Bug reports
|
||||
There are dozens of patches floating around. Some are outdated,
|
||||
don't apply cleanly, are obsolete/unneeded. We could try to do
|
||||
some clean-up, and keep only relevent ones.
|
||||
We should also clean up the SF bug tracker. Some bugreports are
|
||||
very old and we asked for more information with no response.
|
||||
|
||||
16. Small others things
|
||||
16.1 add support for multiple boot devices
|
||||
16.2 add keyboard leds to GUIs
|
||||
16.3 add activity leds (net, disks, floppies) to GUIs
|
||||
Volker added a status bar to the win32 simulation window.
|
||||
It can be used to display leds. The status bar still needs
|
||||
to be implemented by other display libraries.
|
||||
|
||||
17. Positions
|
||||
If you want to help without coding, here are available positions :
|
||||
17.1 Webmaster : update website (Jan Bruun Andersen offered to help)
|
||||
17.2 patch coordonator : look at incoming patches (sourceforge and
|
||||
mailing list) and upload / update in the cvs patches directory.
|
||||
17.3 platform maintainers for macos / win32
|
||||
17.4 disk image maintainer : create and maintain our collection
|
||||
of disk images. Usually, only the configuration file needs to be
|
||||
updated, and old bios files have to be removed. Some packages
|
||||
still contain very old bios files, they should definitely have
|
||||
to be removed.
|
||||
|
||||
18. Bochs demo cd/dvd
|
||||
With version 2.1, it is now technically possible to use disk images
|
||||
on a read-only media, with a journal files on a read/write media.
|
||||
It would be great to create a demo cd/dvd with executables for
|
||||
supported platforms, configuration files and read-only disk
|
||||
images, the journal files would be written in a temporary
|
||||
directory on the harddisk.
|
||||
|
||||
19. Other CPU architectures : arm, ppc
|
||||
This has been asked in the mailing list. I'm not really
|
||||
interested, but other people might be. Should we propose to
|
||||
host the new CPUs code in our source tree, or should we let
|
||||
people fork ?
|
||||
|
||||
20. Config file and dynamic menu
|
||||
20.1 Benjamen R. Meyer wrote :
|
||||
I think we should rework the .bochsrc file to be more standard across all
|
||||
devices. I like how the USB configuration is done in it, and think we should
|
||||
put something similar together for everything else. In otherwords, create
|
||||
something that can be easily used for everything, and make it easier to
|
||||
configure in the process.
|
||||
From what I can tell right now, most of the configuration lines are randomly
|
||||
thrown together as each gets implemented or added, instead of having
|
||||
something that is based on a standard approach to the configuration.
|
||||
The result should be something that would be able to easily auto-configured
|
||||
by another program (a configuration editor?) with minimal changes necessary
|
||||
when new devices/features are added.
|
||||
20.2 Franck Cornelis wrote : the config system needs some work...
|
||||
e.g. the main menu is static while it could be generated at run-time...
|
||||
the main menu text lives somewhere in a file... while it should be generated
|
||||
at run-time by iterating the main menu objects
|
||||
|
||||
21. APIC and windows NT SMP. Stanislav wrote :
|
||||
Current Bochs SMP is almost unusable. I not succeed to boot any SMP OS I
|
||||
have due to APIC problems. Bochs APIC implementation should be reviewed.
|
||||
In the patches folder we already have at least 3 patches for APIC, I hope
|
||||
one of them or their combination will fix the problem or approach my
|
||||
WINNT SMP boot tries.
|
||||
|
||||
22. add to the roadmap that we should find some ideas to check
|
||||
correctness of instructions emulation, especially system instructions.
|
||||
arithmetic instructions could be validated with simply random testing
|
||||
|
||||
23. lowlevel serial support for Windows.
|
||||
Volker is currently working on this.
|
||||
|
||||
24. runtime configuration dialog box for Windows
|
||||
Volker is currently working on this.
|
||||
|
||||
25. Parallel port
|
||||
Conn Clark wrote :
|
||||
I would like to see better parallel port support so I can use a dongle.
|
||||
This is something I would find very useful as it would mean I wouldn't
|
||||
have to boot back into windows ever again. I also recognize that this
|
||||
may require a kernel module be written, which is beyond my current
|
||||
skills. I know others will find this useful as I have had to tell a
|
||||
few people that their parallel port driven peripherals that require a
|
||||
bidirectional parallel port won't work.
|
Loading…
Reference in New Issue
Block a user