kernel device drivers: copy_to/from_user

First, the obvious question: Why would you want to do that? The answer is, I wrote the node read/write functions first and I'm lazy and just want to wrapper that for the ioctl() implementation.

Now my question: Can I use copy_to/from_user on kernel memory? Looking at the code for it (which is mostly assembly) it looks like it should work without any problems, but I just want to be sure that I can actually do that. If not, I'll rewrite my read/write commands to be wrappers for the internal read and write of the device.

Thanks in advance for any help -- and BTW, this ain't no stinkin' homework ;).

[EDIT]
What if I allocate memory with GFP_USER, then send that buffer along the line to the "real" buffer? Would that suffice the copy_to/from_user()?

Okay, I have answers, but none are pretty (and I don't even know if it is cross platform -- so I cannot use it as I'm on the ARM not the x86).

Option 1) there is a section of code that looks something like this:

Code:

---

mm_segment_t* old_fs;
old_fs = get_fs();
set_fs(KERNEL_DS);
/* call the kernel functions */
set_fs(old_fs);

---

But, as I stated, this code works for the x86 and I don't know about the other platforms.

Option 2) Allocate memory with kmalloc in GFP_USER space. I have know idea whether that would work and I don't like the idea of the overhead anyways.

Option 3) ((this is the one I did)) The call that I was wanting to use was a call from my ioctl() to my read and write functions that are registered. Being that these are registered, both must follow the format

Code:

---

ssize_t *read(struct file *, char __user *, size_t, loff_t *)

---

and write is about the same thing. I had to adjust this code to look for something that might clue me in that this is an in-house read. I don't use loff_t * in my code as this is not that kind of driver. If this pointer is NULL, I build a struct that I send back up to the user from the ioctl() and use copy_to_user() to copy the kernel space struct up to the buf supplied. Dreadful hack, I know, but we'll see if it works.

If you have anything better to add, please pass it along.

Andy