rtems-libbsd copyinstr

Sebastian Huber sebastian.huber at embedded-brains.de
Fri Apr 20 07:11:01 UTC 2012


On 04/19/2012 08:44 PM, Joel Sherrill wrote:
> On 04/19/2012 01:59 AM, Sebastian Huber wrote:
>> On 04/18/2012 05:54 PM, Joel Sherrill wrote:
>>> On 04/18/2012 10:33 AM, Sebastian Huber wrote:
>>>> On 04/18/2012 04:59 PM, Joel Sherrill wrote:
>>>>> Hi,
>>>>>
>>>>> copyinstr is currently undefined. According to cscope,
>>>>> it is only defined in
>>>>>
>>>>> powerpc/aim/copyinout.c
>>>>> powerpc/booke/copyinout.c
>>>>>
>>>>> in the source we are using. But when I look where it is
>>>>> referenced in rtems-libbsd, it should have a generic
>>>>> implementation. And these files have much more than this
>>>>> one routine.
>>>>>
>>>>> Any thoughts?
>>>>>
>>>> I think these are the user/kernel space copy routines. Do we need them at all?
>>>>
>>> My gut was that we could have our own implementation which
>>> called memcpy. We don't have user/kernel space but it does appear
>>> to be copying data.
>>>
>> These functions are documented here:
>>
>> http://www.freebsd.org/cgi/man.cgi?query=copy
>>
>> Maybe it is sufficient so simply assign the kernel address to the user pointer
>> and vice versa?
>>
>  From the man page linked to...
>
> The copy functions are designed to copy contiguous data from one address
> to another. All but copystr() copy data from user-space to kernel-space
> or vice-versa.
>
> I propose we implement those needed with memmove() in case the
> addresses are overlapping.

In FreeBSD this is an error condition (EFAULT).  Just look at the implementations.

>
> If the source and destination addresses are the same,

In FreeBSD this is an error condition (EFAULT).

> then
> we could just return and avoid it. I don't know if this happens though.
> But memmove() is save.
>

-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.



More information about the devel mailing list