From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stas Sergeev Subject: Re: various dosemu comments and hacks (sound, delays) Date: Mon, 24 Feb 2003 22:55:54 +0300 Sender: linux-msdos-owner@vger.kernel.org Message-ID: <3E5A78CA.8070603@yahoo.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: linux-msdos@vger.kernel.org Hello. Ryan Underwood wrote: > The precision is not the problem as much as having the context switch time > within every iteration of that loop is really bad for performance. e.g., > even nanosleep(0) incurs a way too much performance hit. Of course that depends on the frequency of that switching. That's why it is better do reduce that freq by doing a syscall not every time the access to the register is done. > Ok.. my implementation is going to be with a separate process because I > am developing adlib server for other reasons too, so my code will be > re-usable. Yep, the standalone adlib server would probably be good to have. Just wondering where can it be used besides dosemu? > The adlib server will either emulate the adlib card or pass through the writes > to real OPL hardware (e.g., /dev/dmfm*). Alternately it could be done the > other way around; have the client program (e.g. dosemu) write to /dev/dmfm, > and depending on the driver that is installed, either the driver writes to > real adlib hardware, or an emulation driver stub registers /dev/dmfm and > forwards the writes to userspace emulation daemon, which then outputs to > /dev/dsp. > Which way do you think is better? Well, ALSA have everything necessary for doing it the second way. That's how the timidity sequencer for ALSA work it seems. So writing the ALSA support for that may be better I guess, but from dosemu's side I think it is about the same which rules are to follow. > Hmm, what do you mean by "all the glibc functions"? There are many glibc > functions that require re-entrant replacements to be used when threading > is involved. Of course, but in the case I am talking about, the threading was not actually involved. What I've done is just added a -lpthread to the linker options and it was enough to get a non-functional dosemu. Weird. >> I've been recently exploring the power >> of the Async IO > So, basically, it seems to be a non-blocking form of polling? No, that's something similar to the interrupt-driven IO. When IO is possible you get a SIGIO (or another signal if you want), you do the IO and get back to work. I.e. no polling is involved, no waiting in select(), no threading etc. > I think #2 is the promising one, but it will be some work. I think the 2 is the only possibility for something real but if you can really get as far as that, then why limiting yourself with VCPI? If you do your #2, you'll be able to just execute any priveleged code, so in that case it will be possible to just load a VCPI server of QEMM etc. I.e. no need to implement a VCPI inside dosemu then. Yeah, that would be great. Btw, we have a simx86 CPU emulator for this. It was rather functional but currently it is in a bizarre state due to a lack of a maintainer. So it might be much easier to resurrect the simx86 and implement some missing features to it rather than using a bochs as a CPU-emu server as you suggested. Anyway this was a long-standing dream for dosemu to be able to execute a ring0 code and so far noone had any success with it, so good luck with that work. But also it turned out recently that even a DPMI can do quite a lot if it is designed properly:)