copy_to_user() with offset

[matth1j]

Hi- can I write:

char __user *userAddr;
char kernAddr;
unsigned offset, n;
:
copy_to_user(userAddr + offset, kernAddr, n);

to copy n bytes from kernAddr[0..n-1] in kernel space into usrAddr[offset..offset+n-1] in user space?

I don't really understand how the user/kernel memory division works, so apologies if this is a silly question.

Regards,
John

[dilbert]

I also don't understand how it "really" works ...

But if it is defined as a pointer to a char array, you can use offsets as long as your offset doesn't end up somewhere else.

BTW: Why don't you use a multiple of the sizeof of that array, but an ordinary unsigned number instead for your offset?

[matth1j]

Thanks for your reply dilbert.

But if it is defined as a pointer to a char array, you can use offsets as long as your offset doesn't end up somewhere else.

What I am worried about is whether the user space memory is contiguous when 'seen' from the kernel ie. whether userAddr[0] and userAddr[1] are actually next to each other. Just to confirm, you are saying that they are?

BTW: Why don't you use a multiple of the sizeof of that array, but an ordinary unsigned number instead for your offset?

Sorry- it's Monday and I'm not quite with it. Please could you give an example?

John

[dilbert]

Surely, the memory is on both sides, kernel and user, contiguous. It would be the hit if it wasn't.

But I don't know what's the amximum size and other constraints. I don't know if it was necessary or not, but I used a special structure type for that with kernel 2.4. Also, I used a checking function in front of it. I guess, all this changed now with kernel 2.6. But you still will have a return value that you can check for errors.

So, you don't know how it's working, but al least if it's working.

Therefore, if you have a larger array or are concerned anyway, you could find out what the constraints are and where they are comfigured.

For offsets in an array, it is always a bad idea to do your own platform-dependent pointer maths.
Better do it that way:

copy_to_user(userAddr + (offset * sizeof (userAddr[0])), kernAddr, n);

This independent from the memory size of an array element.

[matth1j]

Surely, the memory is on both sides, kernel and user, contiguous. It would be the hit if it wasn't.

But I don't know what's the amximum size and other constraints. I don't know if it was necessary or not, but I used a special structure type for that with kernel 2.4. Also, I used a checking function in front of it. I guess, all this changed now with kernel 2.6. But you still will have a return value that you can check for errors.

Good idea.

For offsets in an array, it is always a bad idea to do your own platform-dependent pointer maths.
Better do it that way:

copy_to_user(userAddr + (offset * sizeof (userAddr[0])), kernAddr, n);

This independent from the memory size of an array element.

Right, I understand now. In fact userAddr is a generic pointer to different arrays, and the array element size has already been taken into account in the calculation of offset. But it would still be good to use sizeof as you suggest.

Thanks for your help.

John