From: Jan Engelhardt
Date: Fri, 10 Aug 2012 14:51:49 +0200 (CEST)
>
> On Saturday 2012-07-21 02:46, David Miller wrote:
>>> Arnd Bergmann wrote:
>>>
I don't generally like to put stuff into asm-generic when it's unlikely
to be overridden by architectures. It would really belong into
On Saturday 2012-07-21 02:46, David Miller wrote:
>> Arnd Bergmann wrote:
>>
>>> I don't generally like to put stuff into asm-generic when it's unlikely
>>> to be overridden by architectures. It would really belong into
>>> include/linux, but then again we have all the other bitops in
On Saturday 2012-07-21 02:46, David Miller wrote:
Arnd Bergmann a...@arndb.de wrote:
I don't generally like to put stuff into asm-generic when it's unlikely
to be overridden by architectures. It would really belong into
include/linux, but then again we have all the other bitops in
From: Jan Engelhardt jeng...@inai.de
Date: Fri, 10 Aug 2012 14:51:49 +0200 (CEST)
On Saturday 2012-07-21 02:46, David Miller wrote:
Arnd Bergmann a...@arndb.de wrote:
I don't generally like to put stuff into asm-generic when it's unlikely
to be overridden by architectures. It would really
On Friday 20 July 2012, David Howells wrote:
>
> Arnd Bergmann wrote:
>
> > I don't generally like to put stuff into asm-generic when it's unlikely
> > to be overridden by architectures. It would really belong into
> > include/linux, but then again we have all the other bitops in asm-generic
>
On Friday 20 July 2012, David Howells wrote:
Arnd Bergmann a...@arndb.de wrote:
I don't generally like to put stuff into asm-generic when it's unlikely
to be overridden by architectures. It would really belong into
include/linux, but then again we have all the other bitops in
From: David Howells
Date: Fri, 20 Jul 2012 15:21:39 +0100
> Arnd Bergmann wrote:
>
>> I don't generally like to put stuff into asm-generic when it's unlikely
>> to be overridden by architectures. It would really belong into
>> include/linux, but then again we have all the other bitops in
Arnd Bergmann wrote:
> I don't generally like to put stuff into asm-generic when it's unlikely
> to be overridden by architectures. It would really belong into
> include/linux, but then again we have all the other bitops in asm-generic
> as well, so whatever...
Some arches (such as Sparc, I
On Friday 20 July 2012, David Howells wrote:
> Provide count_leading/trailing_zeros() macros based on extant arch bit
> scanning
> functions rather than reimplementing from scratch in MPILIB.
>
> Whilst we're at it, turn count_foo_zeros(n, x) into n = count_foo_zeros(x).
>
> Also move the
Provide count_leading/trailing_zeros() macros based on extant arch bit scanning
functions rather than reimplementing from scratch in MPILIB.
Whilst we're at it, turn count_foo_zeros(n, x) into n = count_foo_zeros(x).
Also move the definition to asm-generic as other people may be interested in
Provide count_leading/trailing_zeros() macros based on extant arch bit scanning
functions rather than reimplementing from scratch in MPILIB.
Whilst we're at it, turn count_foo_zeros(n, x) into n = count_foo_zeros(x).
Also move the definition to asm-generic as other people may be interested in
On Friday 20 July 2012, David Howells wrote:
Provide count_leading/trailing_zeros() macros based on extant arch bit
scanning
functions rather than reimplementing from scratch in MPILIB.
Whilst we're at it, turn count_foo_zeros(n, x) into n = count_foo_zeros(x).
Also move the definition
Arnd Bergmann a...@arndb.de wrote:
I don't generally like to put stuff into asm-generic when it's unlikely
to be overridden by architectures. It would really belong into
include/linux, but then again we have all the other bitops in asm-generic
as well, so whatever...
Some arches (such as
From: David Howells dhowe...@redhat.com
Date: Fri, 20 Jul 2012 15:21:39 +0100
Arnd Bergmann a...@arndb.de wrote:
I don't generally like to put stuff into asm-generic when it's unlikely
to be overridden by architectures. It would really belong into
include/linux, but then again we have all
On Fri, 6 Jul 2012, David Howells wrote:
> Provide count_leading/trailing_zeros() macros based on extant arch bit
> scanning
> functions rather than reimplementing from scratch in MPILIB.
>
> Whilst we're at it, turn count_foo_zeros(n, x) into n = count_foo_zeros(x).
>
> Also move the
On Fri, 6 Jul 2012, David Howells wrote:
Provide count_leading/trailing_zeros() macros based on extant arch bit
scanning
functions rather than reimplementing from scratch in MPILIB.
Whilst we're at it, turn count_foo_zeros(n, x) into n = count_foo_zeros(x).
Also move the definition to
Provide count_leading/trailing_zeros() macros based on extant arch bit scanning
functions rather than reimplementing from scratch in MPILIB.
Whilst we're at it, turn count_foo_zeros(n, x) into n = count_foo_zeros(x).
Also move the definition to asm-generic as other people may be interested in
Provide count_leading/trailing_zeros() macros based on extant arch bit scanning
functions rather than reimplementing from scratch in MPILIB.
Whilst we're at it, turn count_foo_zeros(n, x) into n = count_foo_zeros(x).
Also move the definition to asm-generic as other people may be interested in
18 matches
Mail list logo
