Direct Memory Access with C

NCC-1701&NCC-1701-D · 06-18-2005, 06:38 AM

Hi all,

I'm just wondering if and how direct memory access with C is possible. As I was examining the MINIX/LINUX source, I found some lines like
#define MEM_LOC 0x<memory address>

Well, can I directly access the memory by giving the hex location and how?
Thanks!

jonaskoelker · 06-18-2005, 07:41 AM

Quote:

As I was examining the MINIX/LINUX source

Uh?

I know there's a kernel named MINIX, and a kernel named LINUX, but I haven't heard of one named MINIX/LINUX--and I wouldn't think they're diff equal for any non-random number of lines.

--

But anyways. You don't get segfaults in kernel mode

And that's basically why you can access any part of the memory. If you're looking for the code to do it, try:

Code:

void* p = (void*) 0xDeadBeef;
/* and then you can do stuff like */
memcpy(p, &foostruct, sizeof(foostruct));

But watch out for endian-ness if you do stuff like that

(like we haven't already chugged any hope of portability).

hth --Jonas

NCC-1701&NCC-1701-D · 06-18-2005, 07:48 AM

Thanks! I meant Linux and Minix, sorry!

jlliagre · 06-18-2005, 08:36 AM

Beware that the operating system (minix, linux, unix, ...) is running the kernel and all processes in virtual memory, so if by "direct memory access" you mean physical RAM access, pointers are of no use.
/dev/mem on linux or solaris is giving you access to the physical RAM content and /dev/kmem the virtual memory used by the kernel.

jonaskoelker · 06-18-2005, 08:39 AM

Quote:

...pointers are of no use.

Good point!

lowpro2k3 · 06-18-2005, 09:40 AM

Quote:

Originally posted by jlliagre
...so if by "direct memory access" you mean physical RAM access, pointers are of no use.

Can someone explain this?

jonaskoelker · 06-18-2005, 10:07 AM

Quote:

Can someone explain this?

I'll try.

The kernel does virtual memory.

Values of pointers are virtual addresses, which the kernel will translate into physical addresses for you.

So, when you read from address 0xDeadBeef, the kernel looks up in a table that the virtual address 0xDeadBeef is either:
1) Not allocated (gives you a segfault)
2) Allocated at physical address such-and-such; the kernel then reads from that physical address and gives you the value.

In practice it's a little bit more complicated--the memory is allocated in blocks called pages. The kernel has to look up the page number and calculate the offset into the page.

Capice?

--Jonas

jlliagre · 06-19-2005, 06:14 AM

There's a third case:
3) allocated, but not mapped to physical memory, a page-fault is generated and the memory is retrieved from the swap space (paging space actually) by the kernel. After that, the process is resumed.

Also a comment on 2), that's not really the kernel that returns a virtual address content, but the mmu.

jonaskoelker · 06-19-2005, 12:40 PM

(3) is a good point--you probably know much more about `kernel stuff' than I do

Quote:

Not really the kernel .. but the mmu.

...If there is an mmu.

I rest my case with the conclusion that `for various reasons, pointer != phys mem'

jlliagre · 06-19-2005, 05:01 PM

Quote:

...If there is an mmu.

There's always one when virtual memory is supported.
Last time I had a Unix (in that case unix like) without an mmu, that was an Atari 520ST under Minix about 20 years ago.
The problem was there was neither virtual memory, so the system was pretty unreliable (no memory protection between processes).
I guess ucLinux is providing the same kind of features for embbeded systems with no mmu nowadays.

jonaskoelker · 06-19-2005, 05:06 PM

Quote:

There's always one when virtual memory is supported.

... but it might be implemented in software as opposed to hardware?
(that was what I meant--sorry to make it unclear).

--Jonas

jlliagre · 06-19-2005, 07:27 PM

There's no such thing as a software MMU unless the CPU is also implemented in software, like with QEMU for example.

jonaskoelker · 06-20-2005, 12:26 AM

Oh...
/me reads some more homework