Linux User space Access Physical address __linux

Because the project requires, you need to access the actual physical address in Linux userspace.

i) User space can be accessed directly by opening the/DEV/MEM device file and then mmap () innuendo

static int Read_type ()
{
	void * map_base;
	FILE *f;
	int type,fd;

#define		READ_REG32 (REG)		(* (volatile int *) (reg))
#define		alloc_size			(1024)

	fd = open ("/ Dev/mem ", O_RDWR | O_sync);
	if (FD)	{
		printf ("Success to Open/dev/mem fd=%08x\n", FD);
	}
	else {
		printf ("Fail to Open/dev/mem fd=%08x\n", FD);	
	}
	Map_base = mmap (0, Alloc_size, Prot_read, Map_private, FD, 0x35004000);

	Type = READ_REG32 (Map_base + 0x20);

	Close (FD);
	Munmap (Map_base, alloc_size);

	printf ("reg32[%08x] = value[%08x] \ n", map_base, type);

	Type = (Type & (1 <<)) >>;

	printf ("reg32[%08x] = value[%08x] \ n", map_base, type);

	return type;
}

Mmap, through the kernel to create a virtual address to the map of the physical address, and then through this virtual address can access the real physical address in user space

Mmap () There are several parameters that need to be described: Prot_read area readable, prot_write area writable, map_shared write data to the mapped region copied back to the file, and other processes that map the file are shared.

The result of the actual operation on Android 4.4: Compiling the generated user space executable program requires root user permission to run. Even if the program itself is already a rwx-rwx-rwx permission. The mapped buffer in mmap () must be an integer multiple of the PAGE size. If not, it will produce segmentation fault. The physical address that is actually accessed, if it is not exactly the integer multiple of page size, must have a corresponding offset to the mapped base address returned by Mmap (), resulting in the final allusion.

II User-space drivers

If user space has access to the actual physical address, you can further implement the hardware drivers for user space.

Advantages of user-space-driven: The complete C library can be connected.  Drivers can do many strange tasks without relying on outside programs (implementing tool programs that use policy, often with the driver itself).  Programmers can run common debuggers on driver code without having to walk a detour to debug a running kernel. If a user space driver hangs up, you can simply kill it.  The drive problem cannot suspend the entire system unless the controlled hardware is really crazy. User memory is interchangeable, unlike kernel memory.  An infrequently used device that has a large drive does not occupy the RAM that other programs can use, except when it is actually in use.  A well-designed driver can still be, like kernel-space-driven, allowing for concurrent access to devices. If you have to write a closed source driver, the user space option makes it easy to avoid the uncertainty of the licensing situation and the changes in the kernel interface caused by the problem.

The device-driven approach to user space has several main drawbacks: interrupts cannot be used in user space.  There are solutions to this limitation on some platforms, such as VM86 system calls on the IA32 system.  DMA can only be used through memory-mapped/dev/mem, and only privileged users can do so. The access I/O port can only be after calling Ioperm or IOPL. In addition, not all platforms support these system calls, while access/dev/port may be too slow and inefficient.  These system calls and device files require privileged users. Response time is slow because context switching is required to pass information or actions between customers and hardware.

Worse, if the drive has been swapped to the hard drive, the response time is not acceptable. Using Mlock system calls can be helpful, but often you will need to lock up a lot of memory pages because a user-space program relies on a lot of library code.  Mlock, also, is restricted to authorized users. The most important devices cannot be processed in user space, including but not limited to, network interfaces and block devices.

As you can see, user-space-driven things can't be done after all too much. Applications that are interested are still present: for example, support for SCSI scanner devices (implemented by the SANE package) and CD burner (implemented by Cdrecord and other tools). In both cases, the user-level device condition relies on the "SCSI gneric" kernel driver, which outputs low-level SCSI features to the user program, so they can drive their own hardware.

A situation that works in user space can be meaningful when you start working with new hardware that is not used. This way you can learn to manage your hardware without having to worry about suspending the entire system. Once you've finished, encapsulating the software in a kernel module can be a simple operation.