Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>/dev/mem is okay for simple register peeks and pokes, but once you cross into interrupts and DMA territory, you really should write a kernel-mode driver. What you did for your previous memory-management-less OSes simply doesn't graft well to an General Purpose OS like Linux. </p> <p>You've already thought about the DMA buffer allocation issue. Now, think about the "DMA done" interrupt from your device. How are you going to install an Interrupt Service Routine?</p> <p>Besides, /dev/mem is typically locked out for non-root users, so it's not very practical for general use. Sure, you could chmod it, but then you've opened a big security hole in the system.</p> <p>If you are trying to keep the driver code base similar between the OSes, you should consider refactoring it into separate user &amp; kernel mode layers with an IOCTL-like interface in-between. If you write the user-mode portion as a generic library of C code, it should be easy to port between Linux and other OSes. The OS-specific part is the kernel-mode code. (We use this kind of approach for our drivers.)</p> <p>It seems like you have already concluded that it's time to write a kernel-driver, so you're on the right track. The only advice I can add is to read these books cover-to-cover.</p> <p><a href="http://oreilly.com/catalog/9780596005900/" rel="nofollow noreferrer">Linux Device Drivers</a></p> <p><a href="http://oreilly.com/catalog/9780596005658/?CMP=AFC-ak_book&amp;ATT=Understanding+the+Linux+Kernel" rel="nofollow noreferrer">Understanding the Linux Kernel</a></p> <p>(Keep in mind that these books are circa-2005, so the information is a bit dated.)</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload