about 64-bits division in kernel

[miloody@gmail.com (loody)]

hi Dave:
Thanks for your kind reply.
2011/5/20 Dave Hylands <dhylands@gmail.com>:
> Hi lody,
>
> On Thu, May 19, 2011 at 8:34 PM, loody <miloody@gmail.com> wrote:
>> hi all:
>> My platform is 32-bits cpu and I need following calculation in my driver.
>> #define longdiv(sr1, sr2, div) ? ? ?(unsigned long )((((unsigned long
>> long)(sr1) << 32) ^ (sr2)) / (div))
>>
>> my question are:
>> 1. why "__udivdi3" has any relationship with above calculation?
>
> Because you're doing 64 bit arithmetic (unsigned long long) and 64 bit
> division is not supported in all kernels.

why the name "__udivdi3" has relation to 64-bits arighmetic?
Why linker ask for "__udivdi3", it seems there is a common sense for
linker that when doing 64-bits calculation it will try to find
"__udivdi3", am i right?

>
>> 2. I know the above calculation is implemented in clibc, but why
>> kernel still implement itself?
>> ? ? why kernel try to make another wheel instead of including what
>> clib provided ?
>
> The kernel doesn't use anything from the C runtime ?library at all.
>
> 64-bit division and floating point are 2 things not supported in the
> kernel, although they do happen to word on some platforms, they aren't
> portable operations.
>
the 64-bit division seem supported in gcc toolchain, and gcc will take
care the platform issue when we cross-compile the gcc, right?
It should be safe to static link the 64bits division in gcc.

-- 
Regards,