Not really. mmap() doesn't create a virtual resource, all it does is read a file and plonk it's data in memory, then when you unmap it, all the changes get written back. You also don't access the mapped data using the usual fread() functions, you just select the bytes in memory to read/write.
It is a lot more versatile than that, and you may as well map files that are way too large to copy them into memory. The file is effectively split into chunks which are a multiple of the page size, those can be loaded on demand simply by leaving their memory pages configured as inaccessable, triggering an interrupt that makes the kernel load the requested page into memory. The kernel may as well decide to drop some pages again to free up memory - on a shared mapping this may actually trigger an update of those parts of the file on disk without calling munmap() or msync(), in contrast to private mappings they are explicitly meant to change the file and therefore only require msync()/munmap() to make sure that there's no data left to be written at a given point.
(I keep wanting to spell it with an 's', though I don't know if that's "legitimate" or me just being English).
My dictionary tells me the British seem to use both spellings, though the 's' one seems to be the preferred one, naturally. I simply prefer the American spelling.
I would say that I would go with "software pretending to be hardware" is virtualization to me, but hypervisors sort of screw that up. So how about "hardware being shown as available, but that isn't physically there". I think this covers me. If you set up a VM with a single core CPU, even if the code runs on a real CPU core, the "single core CPU" known to the VM doesn't really exist. Using TrueCrypt to mount a virtual disk - It shows up as a disk drive, accessed with the usual disk functions, but is driven by software. Paging files because they are virtual memory blocks. An emulator is virtualization of a machine because all of the h/w components are constructed by software
I'd stick with the term "mediated access".
Talking about virtual drives is a bit fuzzy due to the way the OS handles disk accesses within userspace, the representation of a file on disk is already some kind of virtualization - TrueCrypt is acting just like a common filesystem driver, in the case of using it with a file you simply stack one filesystem driver ontop of another one, which is actually doable with other "normal" filesystem drivers as well. A mounted filesystem from a physical disk is not any less virtual than the one representing the content of a virtual disk.
Virtualized non-existent hardware equals being useless in the sense that it can't do anything, it may only influence things by its sole existence. For example, let's say you have a program that wants to output audio but totally refuses to work because the system tells it that it can't find any sound card. In this case a virtualized sound card can make it work without doing anything, you just need to virtualize /dev/null into it, the sound card does not need to behave in a certain way because that part is hidden behind a replaceable driver. On the other hand, DOSBox e.g. needs to fully emulate a sound card because it is not being abstracted though a system API, the program expects the hardware to behave in a certain way, virtualization can only happen if you already have hardware that behaves exactly as required.
Emulation origins from the IBM S/360 series, they were already using techniques similar to the more modern Chinese Loongson MIPS CPU to execute programs created for incompatible predecessor machines by included a little bit more hardware and modified microcode to wire everything up with the already existing function blocks. However, even those would require a special emulation program. Similarly, the Loongson CPU sacrificed 5% of its die space for adding in x86 compatibility, but still only supports a subset that has to be expanded through an emulator as well, even though it may actually achieve 70% of native performance this way by using those hardware-emulated pseudo-native commands. In this context virtualization of the hardware-emulated CPU architecture would only work if it was acting like a fully featured CPU, which is something that apparently has yet to be done in a way that does not involve simply including a full CPU core (Itanium got rather close to that goal, though).
Not only that, but as I understand it, newer Windows applications built for ARM should be able to run in an ARM version of WinE with greater performance due to not having to emulate the architecture, just the OS instructions. Imagine it: Rocket League on a handheld using 4G connection!
