Hi,
Is there a way to temporarily access another page directory when one is already set in CR3? For example, when a process (having its own page layout) needs to write into another one's memory.
for example: when IRQ1 is triggered (does not switch task), I want to write in process X's keyboard buffer, but IRQ1 has been invoked while running a task in process Y, so the addressed memory is not the same.
Of course I tought about changing CR3 temporarily but I'm worried about how much this will cost at runtime.
page directories (IA-32)
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
You can modify the current address space temporarily. You pick a page table entry at init time, then during an interrupt you load it with the physical address of where you want to write, then you write via that page to the buffer. Its faster than changing address spaces as you only need to flush one page from the TLB instead of the entire range.
If you know the address of the other address space's top-level directory, you could recursively descend and find the physical address pointed to by the page you want to modify. Then get a handle to this physical page somehow (you probably already have a way to do this since you have paging working) and write there...
It's a bit messy, but you'd have to do this for Combuster's method anyways, since you need to know which physical address to map the temporary page in at....
If you already have a fast means of accessing arbitrary physical addresses (like a linear-mapped region), this is probably quicker.
It's a bit messy, but you'd have to do this for Combuster's method anyways, since you need to know which physical address to map the temporary page in at....
If you already have a fast means of accessing arbitrary physical addresses (like a linear-mapped region), this is probably quicker.
Neptune - 64 bit microkernel OS in D - www.devlime.com
yes but if the page is swapped, the physical address won't match anymore.
Since every process has its keyboard buffer located at the same virtual address, I guess I could determine the physical addr (everytime a key gets hit, between CLI and STI) from the logical address of process X, modify the keybuf's page entry in the current process so that it is identical to process X's entry and then write to it.
It looks like a good solution but that would be terribly slow. I'm starting to wonder if my design is bad. Would it be logic that every process have its own keybuf and IRQ1 would write in the keybuf of the process currently interracting with user input?
Since every process has its keyboard buffer located at the same virtual address, I guess I could determine the physical addr (everytime a key gets hit, between CLI and STI) from the logical address of process X, modify the keybuf's page entry in the current process so that it is identical to process X's entry and then write to it.
It looks like a good solution but that would be terribly slow. I'm starting to wonder if my design is bad. Would it be logic that every process have its own keybuf and IRQ1 would write in the keybuf of the process currently interracting with user input?
Hi,
Having a seperate special purpose buffer for every possible situation doesn't make that much sense - maybe having a single generic buffer would make more sense...
IMHO it sounds like you need some sort of IPC (pipes or messages or something) that the keyboard IRQ handler (and any other software) can use to send data to another task.
Cheers,
Brendan
That'd work, but it'd only work for keyboard. What about mouse, and joystick, and microphone? What if a task wants the VFS to let it know if a directory's contents changes, or if taskA wants to tell taskB something?dumaisp wrote:Since all process have the kernel memory mapped to the same address, I will make a keyboard buffer in kernel memory.
Having a seperate special purpose buffer for every possible situation doesn't make that much sense - maybe having a single generic buffer would make more sense...
IMHO it sounds like you need some sort of IPC (pipes or messages or something) that the keyboard IRQ handler (and any other software) can use to send data to another task.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.