12.11.2012 07:04, Bart Oldeman пишет: > >> If so (and only if), then this explanation can't help me >> getting rid of the false feeling of a trivial solution, unfortunately. >> For example: >> 1. We prepare the read area in advance. >> 2. We write-protect it. >> 3. On a page fault we mark the page dirty, remove the >> write protection, but set a read protection. No instruction >> decoding happens - we allow the write to succeed directly. >> 4. On a read fault we process the pending writes and goto 1. > Sorry, but PROT_WRITE implies PROT_READ on x86, so that cannot work. Oh no, noooooo... Indeed, I happened to forget that intel sucks. :( PROT_WRITE can still be emulated with TF I think, and, if put into a kernel, it may even still provide a viable performance: AFAIK all the slowdown in the world starts to happen when the signal is sent, but the in-kernel exception handling may still be fine, even in case of 2 exceptions in row (PF and then debug exception from TF). But, knowing intel, I guess the W bit of PF error code will not work if the P bit of the page is not set, so perhaps it won't be possible to find out whether it was the read or write fault if we use PROT_NONE to catch both and filter manually?
------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov _______________________________________________ Dosemu-devel mailing list Dosemu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dosemu-devel
