Mapping off-board memory over a PCIe interface as a tmpfs drive.
Linux - Embedded & Single-board computerThis forum is for the discussion of Linux on both embedded devices and single-board computers (such as the Raspberry Pi, BeagleBoard and PandaBoard). Discussions involving Arduino, plug computers and other micro-controller like devices are also welcome.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Mapping off-board memory over a PCIe interface as a tmpfs drive.
Hi all. I'm interested in discussing ways to map off-board memory to a locally mapped file system.
To explain: I have access to off-board memory, and a kernel module supplied by Xilinx called xdma that is up and running nicely. I define the DMA channel, pass it an address and offset, and I can read/write over the PCIe interface just fine, using interrupts or just polling.
Now I was thinking I could write a block kernel module to interface with the DMA engine, then map the block device as a drive (like a hard drive), and assign a file system to it, and use it like a hard drive.
I'd like to discuss this approach with someone more familiar with linux than myself.
You have it right. Implementing a block driver gets you all the benefits of the standard machinery for dealing with disks and storage. The O'Reilley "Linux Device Drivers" has a chapter on block device drivers, but is not updated since 2005, so some details may have wandered a little. Not sure if there is a better reference.
Basically, you have to implement a request queue for handling the async I/O requests to your device, and some of the calls on the block_device_operations struct (open/close/ioctl). Look at an existing driver for reference. The hard disk (sd.c) and floppy disk (floppy.c) are both pretty big to deal with all the hardware complications, but yours can take a lot of shortcuts.
Awesome. That's what I was looking for. I read the section from O-Reilley https://www.oreilly.com/openbook/lin.../book/ch16.pdf and it seemed appropriate. You're right, it's antiquated.
I'll have a look at sd.c and floppy.c...
Is ioctl still used, or has this been deprecated now? I thought I read somewhere there's another preferred method?
Some userspace code might expect certain ioctls, but I don't think they are absolutely necessary. I'm thinking of equally deprecated software like fdisk. It's simpler to use the /sys interface for new code.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.