How to allow physical memory access, in usermode?

[TylerH]

The point of this is that I want a usermode terminal driver, rather than one built into the kernel. The problem is that the terminal driver would have to have access to the physical address 0xb8000. IMHO, it doesn't sound like a good idea to allow usermode programs to specify what memory they want to use. Is there existing theory on how to solve this? I'm also wondering about how to control IO port usage. I don't want to allow processes to use any port they want to, but yet I see a need for processes to get access to certain port. However, I see no good way of determining if they're requests are warranted.

[gerryg400]

I just do this

Code: Select all

	VidMem = mmap(0, 8192, PROT_READ | PROT_WRITE, MAP_PHYS | MAP_PRIVATE, -1, 0xb8000);

In my mmap code, I only allow processes running as root to use MAP_PHYS. You can be a little cleverer and have a file called /dev/physmem and allow (root) processes to mmap that, but I decided to keep it simple.

[Owen]

If this is a microkernel, then I would

1. Give the root task access to all physical memory
2. Provide a way to subdivide blocks of memory & grant access to them to subprocesses
3. Have the HAL and bus drivers give out appropriate blocks of memory

So, on PC:

1. Root task gives access to all memory to the HAL
2. HAL looks at the list of baked in (i.e. standard ISA) devices and grants access to VGA space to the VGA driver

A potential, more convoluted case:

1. Root task gives access to all memory to the HAL
2. HAL starts up PCI driver, and grants access to all PCI memory to the PCI driver
3. PCI driver gives access to memory ranges to the Firewire driver
4. Firewire driver gives access to disk device memory ranges to the Firewire disk driver

[jal]

The point of this is that I want a usermode terminal driver, rather than one built into the kernel. The problem is that the terminal driver would have to have access to the physical address 0xb8000.

Not, it should not. The terminal driver should tell the VGA driver (that does have access to the physical VGA memory) what to display. A terminal driver must handle input (coming from e.g. the keyboard driver) and must accept characters to display (which may contain escape sequences it must then convert to e.g. position and colour). It must not touch actual memory (think about having multiple terminals, or in a windowed environment).

IMHO, it doesn't sound like a good idea to allow usermode programs to specify what memory they want to use.

It depends. Drivers can run in usermode as well. But applications should not (and a terminal driver is imho more of an application than an actual (hardware) driver).

However, I see no good way of determining if they're requests are warranted.

Have drivers be a special class of executables, that have more privilige than ordinary applications. How to do this depends largely on your OS design.


JAL

[gerryg400]

Not, it should not. The terminal driver should tell the VGA driver (that does have access to the physical VGA memory) what to display. A terminal driver must handle input (coming from e.g. the keyboard driver) and must accept characters to display (which may contain escape sequences it must then convert to e.g. position and colour). It must not touch actual memory (think about having multiple terminals, or in a windowed environment).

'Must' is a very strong word. Surely this is a personal design preference. There doesn't seem to be any compelling reason to have a separate console driver and VGA driver in a text-only system. The console driver can easily drive several consoles by keeping all but one in memory and writing directly to the screen for the one that has focus.

[jal]

'Must' is a very strong word. Surely this is a personal design preference.

You are right that "must" is a strong word, and I agree it is a design choice to make. If no other application will ever have to access the VGA memory but the console driver, having a separate VGA driver may seem a bit too much, especially for the early stages. However, I do not think it is a personal design preference, it must be based on good arguments, not on personal preference. If you are planning on supporting multiple video modes (e.g. 40x25, 80x25, 80x50, 80x60, 90x60, all possible with standard VGA), or planning on supporting graphics modes, that mode-switching code would really call for a separation of function between the terminal code and the display driver code. If on the other hand you rely on the BIOS to set the video mode, and use only memory access to write characters, you could be better of doing that in the console driver.

There doesn't seem to be any compelling reason to have a separate console driver and VGA driver in a text-only system.

Except for see above.

The console driver can easily drive several consoles by keeping all but one in memory and writing directly to the screen for the one that has focus.

Yes, it can. And like I said, if accessing memory is all you need, a separate driver would be overhead (although I personally would go for it).


JAL