OSDev.org

Hi,

I have a memory buffer (or even a mmap memory, if that helps), and want to analyze it using another tool. A problem is that the tool only deals with a file, not a memory.

So I am thinking about representing my memory buffer as a file, and then lets my tool to process it. I just need to point my tool to that "file", and it should work as it is a real file.

Is there any clean way to do that?

(I am on Linux, and program in C)

Thanks a lot,
J

What about writing the memory buffer to a file

skyking wrote:What about writing the memory buffer to a file

That is surely possible, but I prefer not to do that if possible. I hope to have another way to do that.

Thanks,
J

Exactly what is the problem? If the other tool is a separate executable the only reasonable option is to output the content via a file. If the other tool can accept input from standard in you could of course use pipes to transmit the data.

junkoi wrote:

skyking wrote:What about writing the memory buffer to a file

That is surely possible, but I prefer not to do that if possible. I hope to have another way to do that.

Thanks,
J

Why not? It is the only sensible solution.

In some sense, that is precisely what a pipe was created for. You don't need to turn it into a file -- just output it to stdio.

Hi,
Nope I agree with JamesM here , pipe() wont help if the external program takes in only a filename argument ( ie it does not take form stdin) .

Regards
Shrek

As far as I know, pipes are not seekable, thus useless if the program needs random access to the file.

First off, I'm not sure I got this completely right, but it might be of some help.

Anyhow, as said before, if the function takes the name of the file, you're pretty much stuck. As any function loading files goes through either the C library (which then redirects to your kernel) or directly your kernel, you have to specify how the file loading goes, and so you're free to point the function to the memory where the "file" is. A "file" is just something on a storage device that gets loaded into memory later, so it's nothing but a load of bytes and eventually, file handling should be the same as memory handling.

You just need to make sure that the function gets pointed to the correct place in memory as it has no choice but to go through your kernel to open the file.

Hi,

I'm not sure I quite get what you are trying to do, but if you really don't want to write a file to disk, how about implementing a ramdisk to do the job?

Cheers,
Adam

The premises are not fully specified in the original post. We do not know if the tool is a separate executable or just a library function, we do not know if the tool requires a filename as argument or if it can work on a supplied open file (which would be STDIN_FILENO in the case of separate executable), we do not know if the tool requires to perform random access on the file or if the input is processed in sequential order and we do not know if the tool does read/write accesses or only read accesses (or even write only). Any combination of these alternatives should be possible (although i don't think it's likely that a program that accepts input via stdin would try to use random access).

If the tool requires a filename you pretty much bound to have a named file or named pipe, whether it's on tmpfs, ramfs or another filesystem is up to you. If it's not you can use anonymous file or anonymous pipe.