OSDev.org

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.

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.

Actually, when you set up that buffer, you can store the physical address of that buffer as part of the process

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?

dumaisp wrote:yes but if the page is swapped, the physical address won't match anymore.

Locking, anyone?

Seriously, if you want an IRQ handler to write to a memory buffer that can be swapped out, what fast method are you going to use when that buffer got paged to disk? </rhetoric question>

If you are talking about locking the page, yes I could do that. But it would have to be locked 100% of the time. Unless I decode the address from the logical address everytime.

OK I just figured it out.

basicaly its the same thing you said.
Since all process have the kernel memory mapped to the same address, I will make a keyboard buffer in kernel memory. That page will change everytime a new process is interracting with the user

Hi,

dumaisp wrote:Since all process have the kernel memory mapped to the same address, I will make a keyboard buffer in kernel memory.

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?

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