1 This is the "roadmap" posted in the mailing list, augmented by
2 comments from the mailing list and the irc chat.
3 Anybody is welcome to work on any of these issues. Some of
4 these items are rather simple and can be implemented by single
5 individuals. Other items are quite complex and development needs
6 to be coordonated. So, if you want to contribute, please drop
7 us a note in the mailing list, so you can get help or exchange
12 Source Forge recently set up a donation system for hosted projects.
13 Should we accept donations ? What could we do with the money ?
14 - give to EFF, FSF or other
15 - fund Kevin to continue the work on plex86 so we can use it
16 - bounties for somebody write optimized win9x/NT/XFree/linux/*BSD
17 drivers for our vga/net/ide cards
20 No decisions about this yet.
23 Speed (well lack of) is one of the biggest criticism made by users
24 who'd like to see Bochs run as fast as Virtual PC.
25 Paths we can explore to get more speed :
26 4.1 virtualization : plex86
27 4.2 dynamic translation : qemu, patch from h.johansson
28 4.3 optimizations of instructions path / host asm (Conn Clark has been
29 working on this, and an anonymous patch for win32
30 http://sourceforge.net/tracker/index.php?func=detail&aid=867044&group_id=12580&atid=312580
35 2. Plugin architecture
36 2.1 The plugin architecture can be reworked if we want to support
37 multiple similar devices like seral net or vga cards.
38 We currently have two "types" of plugins: "core" and "optional".
39 Maybe we could add "classes" of plugins. The current version of
40 Bochs supports the classes "display_library" and "io_device".
41 New classes can be "config_interface", "net_lowlevel" and
44 Plugin architecture should be rewritten like real plugin architecture s.t.
45 Bochs VGA plugin for example will be real plugin. I mean that replacement
46 of plugin dll in already compiled Bochs will replace Bochs VGA card and
47 the new card will be detected automatically.
48 This will allow for example developing of plugins separately from Bochs.
49 2.3 Michael Brown wrote :
50 If the configuration interface is to be reworked, could we also make it so
51 that plugins are self-contained, rather than needing to pollute config.cc
52 with code for defining and parsing plugin-specific options
54 A little bit of the basic work is done now: The config parameter handling has
55 been rewritten to a parameter tree and user-defined bochsrc options are now
56 supported. The main plugin architecture rewrite is not done yet.
58 3. PCI host<->guest proxy
59 Being able to use a real pci device from inside Bochs would be a
60 great feature of Bochs. It would ease reverse engineering of non
61 documented cards, or one could even use a real spare vga card.
62 Frank Cornellis has done a great job on this subject, and we began
63 integrating his changes.
65 The pcidev device is present in CVS and it has been updated for the new PCI
66 infrastructure, but the new code is untested yet.
68 4. Subdirectories in iodev
69 The iodev directory contains the various implemented iodevice.
70 With the new pci devices, new harddrives and new net access methods,
71 it could be interesting to add new subdirectories like :
72 iodev/video/... --> for standard vga and new card emulation
73 iodev/disks/... --> for the ata/atapi classes, hd/cd classes and host accesses
74 iodev/net/... --> for ne2k and host net access
75 isa and pci devices would be mixed in the directories, but this should
80 5 multithreading. Conn Clark wrote :
81 Threading might be nice too, for those of us who have SMP/SMT machines.
82 I have a patch from Mathis (who hangs out on the IRC channel all the
83 time) that puts the video card interface in its own thread. It has
84 troubles though that I have not resolved. It may also be easier to debug
85 a threaded peripheral.
86 I also think that it might be possible to thread a chunk of the CPU
87 emulation to improve performance on a SMP/SMT machine. Specificaly
88 write_virtual_dword, write_virtual_word, write_virtual_byte, etc...
89 might just be able to be threaded. I think the threading overhead might
90 be less than the protection and address translation code. We would have
91 to try it to find out. I'm also sure there can be some nasty hurdles to
94 Third party proup started a para-Bochs project exacly to reach above goals,
95 some beta version is already released.
96 The home page of the project: http://grid.hust.edu.cn/cluster/VirtualMachine/index.html
99 6.1 This was asked in the ml, and I believe it's a good idea to provide
100 a configure switch to set the cpu model, for example :
104 --with-cpu-pentium-mmx
107 and so on. The main difficulty here is to set up the list of features
108 by cpu model. I started such a list, available at
109 http://cbothamy.free.fr/projects/bochs/CPU_Features.sxc
110 The configure script will then set up constants on features to compile in,
111 ISA, FPU, MMX, 3DNOW, SSE, etc... Most of the feature flags already
112 exists in config.h, so this should be easy. It would also be a good
113 idea to clean up the cpuid function beased on those flags.
114 We also have to keep in mind that some features are also enablable
116 Please note the all features are still not supported/complete in Bochs.
117 6.2 Stanislav thinks that configure --with-cpu-pentium-mmx --enable-cpu-level-4
118 would create lots of conflicts in the generated config.h. He suggests
119 that we should write an external GUI configure script that would propose
120 standard or custom cpus and would detect conflicts.
125 For SVGA emulation we have Bochs VBE and the Cirrus adapter. We should have
126 a look at the voodoo3 (specs http://v3tv.sourceforge.net/docs.php).
130 8. Random thoughts on disk emulation improvements :
132 8.2 autodetection of disk size / geometry
133 8.3 uml cow disk image support
134 8.4 compressed disk image support
135 8.5 extend redolog-disk specification to add coherency check of the flat
136 image file, by storing its fstat-mtime field in the redolog.
138 Autodetection now works for all image types created with bximage and vmware3
139 images. LBA48 and vmware4 disk images support was added in Bochs 2.3.5 release.
140 The other items are not done yet.
143 9.1 bootable ethernet rom ?
144 see etherboot, Micheal Brown wrote :
145 This already works; you can build an Etherboot rom image with the pnic
146 driver, specify it as an option ROM in bochsrc and it will boot. I'm
147 using this extensively at the moment in Etherboot development.
148 In the Etherboot project's CVS, in the contrib/bochs directory, you can
149 find a working bochsrc file and an up-to-date README with step-by-step
150 instructions on getting this working.
152 The pnic device is present in CVS, but the status is unknown.
155 10.1 our bios is quite heavy on stack space (notably during int13 functions).
156 Some parts can be rewritten in assembler, to save stack space and
159 New BIOS supporting ACPI was introduced in Bochs 2.3.5 release.
161 10.2 add "jump table placeholder" and log missing function calls in the bios.
162 Check completness with Ralf Brown interrupt list.
167 11.1 Video parameters table
168 There is a very nice parameter table in 3dfx banshee document
169 http://www2.lm-sensors.nu/~lm78/pdfs/Banshee_2d_spec.PDF
170 see also http://www.xyzzy.claranet.de/dos/vgacrt.c
172 The new version 0.6a of the LGPL'd VGABIOS has minimal support for the video
175 12. Optimized Guest drivers still needed : VGA, IDE, NET
176 We have a specific VGA driver for winNT/2K, but still
177 lack drivers for other OSes.
182 Ben Lunt has been working on USB support. The USB mouse and keypad code
183 is present in Bochs and almost stable. USB flash disk support has been
184 started and the runtime device change support should be completed.
188 14. Config file and dynamic menu
189 14.1 Benjamen R. Meyer wrote :
190 I think we should rework the .bochsrc file to be more standard across all
191 devices. I like how the USB configuration is done in it, and think we should
192 put something similar together for everything else. In otherwords, create
193 something that can be easily used for everything, and make it easier to
194 configure in the process.
195 From what I can tell right now, most of the configuration lines are randomly
196 thrown together as each gets implemented or added, instead of having
197 something that is based on a standard approach to the configuration.
198 The result should be something that would be able to easily auto-configured
199 by another program (a configuration editor?) with minimal changes necessary
200 when new devices/features are added.
201 14.2 Franck Cornelis wrote : the config system needs some work...
202 e.g. the main menu is static while it could be generated at run-time...
203 the main menu text lives somewhere in a file... while it should be generated
204 at run-time by iterating the main menu objects
206 The config options handling has been rewritten to a parameter tree.
209 Save/restore of config and log options and the hardware state is supported
210 in all Bochs configurations. Harddisk images are not handled yet.
212 16. add to the roadmap that we should find some ideas to check
213 correctness of instructions emulation, especially system instructions.
214 arithmetic instructions could be validated with simply random testing
218 17. lowlevel serial support for Windows.
219 Volker is currently working on this.
221 Not yet complete (transmit works, receive is losing data).
225 I would like to see better parallel port support so I can use a dongle.
226 This is something I would find very useful as it would mean I wouldn't
227 have to boot back into windows ever again. I also recognize that this
228 may require a kernel module be written, which is beyond my current
229 skills. I know others will find this useful as I have had to tell a
230 few people that their parallel port driven peripherals that require a
231 bidirectional parallel port won't work.
235 19. Patches / Bug reports
236 There are dozens of patches floating around. Some are outdated,
237 don't apply cleanly, are obsolete/unneeded. We could try to do
238 some clean-up, and keep only relevent ones.
239 We should also clean up the SF bug tracker. Some bugreports are
240 very old and we asked for more information with no response.
242 There is some progress, but still a lot of work to do.
245 If you want to help without coding, here are available positions :
246 20.1 Webmaster : update website (Jan Bruun Andersen offered to help)
247 22.2 patch coordonator : look at incoming patches (sourceforge and
248 mailing list) and upload / update in the cvs patches directory.
249 20.3 platform maintainers for macos / win32
250 20.4 disk image maintainer : create and maintain our collection
251 of disk images. Usually, only the configuration file needs to be
252 updated, and old bios files have to be removed. Some packages
253 still contain very old bios files, they should definitely have
256 More active developers are needed to do the things described above.
258 21. Bochs demo cd/dvd
259 With version 2.1, it is now technically possible to use disk images
260 on a read-only media, with a journal files on a read/write media.
261 It would be great to create a demo cd/dvd with executables for
262 supported platforms, configuration files and read-only disk
263 images, the journal files would be written in a temporary
264 directory on the harddisk.
268 22. Other CPU architectures : arm, ppc
269 This has been asked in the mailing list. I'm not really
270 interested, but other people might be. Should we propose to
271 host the new CPUs code in our source tree, or should we let