Can driver remember calling application's buffer address?
 

I'm writing a driver for Fedora. It's mostly working but I need to add a feature. My question relates to private or shared memory. I realize a driver may have a type of global [kernel] memory, which will be common to all the code in the driver regardless of which user application called it. I'm wondering if a driver may also have some [kernel] memory that's unique to the user application calling it. And then, or course, I believe I already know the driver can carefully access the user application's own memory.

Specifically, I want the user application to pass a buffer address to the driver, just as it would during a read() call. But for this special call, that will be implemented using a cover function over ioctl, I want the driver to SAVE the address of that buffer. This is going to be an auxiliary status buffer.

Then, later, when the user application calls read() with a read buffer address, I want to not only copy_to_user the read data into the read buffer, I *also* want to copy_to_user some auxiliary information into that auxiliary buffer. In order to do this, of course, the driver needs to remember that buffer address. Also, I believe this code may get executed for multiple calling user applications, so the memory where the driver saves the buffer address needs to be unique per the caller. I believe it may somehow need to tie into the file handle or something. I don't know.

I haven't researched too deeply into this yet. I haven't come up with good search keywords to find the info efficiently. So I'm asking here to get a head start...

Thanks.

Accessing Specific Memory Locations in C

How can you access a memory location using C? their are many more links within that page that may lead you to a better understanding of what it is you need to know as well.

keywords used to find the links and others I did not look at where "memory accessing addresses"

memory: because that is what you are working with.
accessing addresses: because that is what you need to do with the memory.
you could also add what programming language you are using to narrow it down more.

I hope that helps

Thanks, but sorry, you missed my point. I guess I didn't express myself well enough. I have come up with an alternative, so nevermind, I guess.

I think that should be tied to the process id, but probably misunderstood

shifted into never mind mode.. whatever it is you're trying to finagle I hope it works out for you.

Thanks to all. I got it working without the need for the driver to remember anything per caller.

That's definitely an architecture to be preferred. When an application program makes a system-call that refers to a specific (of course ...) virtual address, there's a really good chance that the real-memory pages in question are already available. In any case, the driver will have to force those pages to be resident and locked for the duration, and will have to wait for this if need be. In this scenario, actual waiting is unlikely ... and, because the process/thread is stopped, interference with the application program is much less likely. The application programmer is much less likely to encounter a race-condition, so debugging is much easier.

The nicest way to do it (IMHO ...) is to create a virtual device structure, which the user-land process of course must "open," which gives you a convenient per-process kernel memory area in which to store things. Let the user-land process then "explicitly rendezvous with" the kernel in order to request, and to receive at that moment, anything that it needs to receive.

Thanks for your thoughts. I believe I'm doing what you say. Specifically, there is a virtual device to open. The user application has a status structure that it passes immediately after a traditional open() call, using a device-specific cover function that inside calls ioctl to send the structure to the driver. The driver uses some structure details for configuration. Later, the user application tries to read the device. In the past, I used a traditional read(). Now instead I'm using another device-specific cover function that inside calls ioctl. The cover function also receives a structure pointer (same one as the config, in fact, but different members of interest). So now the user application is calling cover(fp,&struct) rather than read(fp,buffer,len). Inside the driver, copy_from_user() and copy_to_user() are used to get some initial metadata, do the read, and pass metadata back. This structure, in user memory, now contains that metadata that I originally wanted to be memorized by the driver per caller, the original subject of this post.