Memory Mapped Files
Using the Linux mechanism for
direct access to device data
Typical file access senario
•
•
•
•
Use open(), lseek(), read(), write(), close()
Each involves two privilege-transitions
At most 4096 bytes transferred each time
Inefficient for non-sequential data access
Alternative: use ‘mmap()’
•
•
•
•
Take advantage of the paging mechanism
Associate virtual addresses with the data
Similar to ‘swapping’ or ‘page-cacheing’
Simple standard C programming API:
– ‘mmap()’ creates the memory mapping
– ‘munmap()’ deletes the memory mapping
• Example: look at ‘dump.cpp’ on website
Four easy steps
•
•
•
•
1) open the file
2) map the file
3) use the file
4) unmap the file and close the file
Device memory mapping
•
•
•
•
Recall our ‘vram.c’ character driver
Allowed users to access display memory
But lacks efficiency for serious graphics
We implement driver ‘mmap()’ method
‘mmap()’ driver-method
• Ideas from LDD textbook: Chapter 13
• But also required lots of experimentation
• Four steps in the ‘mmap()’ method
1) compute map’s starting-point and length
2) check: cannot map past end-of-memory
3) mark mapped area as ‘non-swappable’
4) request kernel to set up the page-tables
Information from vm_area_struct
•
•
•
•
•
•
‘vm_start’ is starting address in user-space
‘vm_end’ is ending address in user-space
‘vm_pgoff’ is page-offset in device memory
‘vm_page_prot’ is page-protection bitmap
‘vm_flags’ is bitmap of requested attributes
‘EAGAIN’ error-code tells kernel ‘try again’
Comparing execution-times
•
•
•
•
•
•
We ccan use our ‘tsc.c’ device-driver
Step 1: read and save timestamp counter
Step 2: perform our drawing operations
Step 3: read and save timestamp counter
Step 4: subtract timestamp counter values
Step 5: report the number of CPU cycles