Eric Paris <eparis <at> redhat.com> writes: > On Tue, 2007-06-05 at 17:16 -0400, Alan Cox wrote: > > On Tue, Jun 05, 2007 at 05:00:51PM -0400, James Morris wrote: > > > This should be an unsigned long. > > > > > > I wonder if the default should be for this value to be zero (i.e. > > > preserve > > > existing behavior). It could break binaries, albeit potentially insecure > > > > Agreed - DOSemu type apps and lrmi need to map at zero for vm86 > > And so it shall be!
X also needs to be able to map at zero for vm86, which makes this a lot less useful. In particular, the interrupt vectors need to point to the right place within the VBIOS we're calling into, so we have to be able to map the zero page. (And often write to it, if we're posting a non-primary card.) Obviously this isn't so much an issue for non-x86, where you have to use the emulator anyway. And I'm pretty convinced that calling vm86 in a SMP environment is just suicide so you _ought_ to use the emulator even on real x86. We've already got the infrastructure in place to completely fake the real mode address space for the emulator. IWBNI we had some way of presenting a set of virtual-address-space pages as contiguous to the vm86 task, since if we had that we could just malloc 1M, copy in the bits we need, and go. I don't know if vm86 mode supports that in silicon; it certainly isn't exposed in the API. Anyone know? Actually it's a little worse than that. Some chips have an escape hatch where they remap banks of registers into the 64k VGA aperture, and the BIOS relies on this. So some of the pages need to be backed by device mappings, and some by plain memory. You'd really need either an array of pointers to userspace pages, or a trap handler like how vm86 handles I/O cycles. Again, I don't know offhand whether vm86 can do this, but if it does then fixing X to take advantage of it is pretty easy. - ajax - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/