2

Normally MMU-less systems don't have MPU (memory protection unit) as well, there's also no distinction between the user & kernel modes. In such a case, assuming we have a MMU-less system with some piece of hardware which is mapped in CPU address space, does it really make sense to have device drivers in the kernel, if all the hardware resources can be accessed from the userspace?

Does a kernel code have more control over memory, then the usercode?

Mark
  • 6,052
  • 8
  • 61
  • 129

1 Answers1

3

Yes, on platforms without MMUs that host ucLinux it makes sense to do everything as if you had a normal embedded Linux environment. It is a cleaner design to have user applications and services go through their normal interfaces (syscalls, etc.) and have the OS route those kernel requests through to device drivers, file systems, network stack, etc.

Although the kernel does not have more control over the hardware in these circumstances, the actual hardware should only be touched by system software running in the kernel. Not limiting access to the hardware would make debugging things like system resets and memory corruption virtually impossible. This practice also makes your design more portable.

Exceptions may be for user mode debugging binaries that are only used in-house for platform bring-up and diagnostics.

Peter L.
  • 1,041
  • 2
  • 22
  • 26
  • Thanks Peter. On uclinux, is there a way to limit userland applications to access, maybe accidentally, to the hardware registers? – Mark Jan 27 '16 at 20:50
  • @Mark I don't think so. If there is I would be very interested in understanding how. One ucLinux project I worked on had peek and poke utilities that would access any memory directly. However, none of the production user code would do this. The WLAN driver, however, would access the registers it needed to just as it would have on a system using stock Linux. – Peter L. Jan 27 '16 at 21:03
  • Are there significant differences for uclinux driver writing? For example, different implementation of kmalloc, or the details are taken care of under the hood and I don't need to bother about it? – Mark Jan 27 '16 at 21:15
  • @Mark The cool thing about ucLinux is that most of the details regarding kernel implementation of system APIs (kmalloc(), etc.) are taken care of. So, much if not all of the driver source is the same as it is for stock Linux. However, one problem we ran into (years ago) is that the most recent version of ucLinux that supported our Atmel processor was based on the 2.4.x kernel and a 2.6.x port was not available or even possible for that processor. You may want to check that a build of the latest ucLinux kernel is available for your chosen processor, or select a processor that'll work. – Peter L. Jan 27 '16 at 21:50
  • the reason I asked about differences is that http://free-electrons.com/doc/uclinux_introduction.pdf mentions about kmalloc2() API in section "Memory Allocation", however I didn't find this in code. – Mark Jan 28 '16 at 14:09