This is the contents of the "next" branch of
git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git,
as currently found in linux-next.
Only two files are touched, most of the changes are bugfixes
to the lib/checksum.c file that I introduced with the original
asm-generic merge.
If anything is missing here, please tell me.
Diffstat:
include/asm-generic/unistd.h | 4 ++--
lib/checksum.c | 14 ++++++++------
2 files changed, 10 insertions(+), 8 deletions(-)
Full log:
commit 34b2fb828b63aa1178313ed0478955636dcb49be
Author: Chen Liqin <[email protected]>
Date: Mon Oct 26 11:09:29 2009 +0800
asm-generic: Fix typo in asm-generic/unistd.h.
Fixed __NR_ftruncate and __NR_ftruncate64 define in asm-generic/unistd.h.
Signed-off-by: Chen Liqin <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
include/asm-generic/unistd.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
commit 0a5549ed163520787f76b7515dfe9d9aa1c7ae37
Author: Arnd Bergmann <[email protected]>
Date: Tue Jun 23 22:52:51 2009 +0200
lib/checksum: fix one more thinko
When do_csum gets unaligned data, we really need to treat
the first byte as an even byte, not an odd byte, because
we swap the two halves later.
Found by Mike's checksum-selftest module.
Reported-by: Mike Frysinger <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
lib/checksum.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
commit 20c1f641bb80fb272dec959a5caabed92e5a422e
Author: Arnd Bergmann <[email protected]>
Date: Tue Jun 23 21:37:26 2009 +0200
lib/checksum.c: make do_csum optional
Mike Frysinger suggested that do_csum should be optional
so that an architecture can use the generic checksum code
but still provide an optimized fast-path for the most
critical function.
This can mean an implementation using inline assembly,
or in case of Alpha one using 64-bit arithmetic in C.
Cc: Mike Frysinger <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
lib/checksum.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
commit c44ba9f6684946b156335da6a6d55f0b8cf7cb72
Author: Arnd Bergmann <[email protected]>
Date: Tue Jun 23 21:22:58 2009 +0200
lib/checksum.c: use 32-bit arithmetic consistently
The use of 'unsigned long' variables in the 32-bit part of do_csum()
is confusing at best, and potentially broken for long input on 64-bit
machines.
This changes the code to use 'unsigned int' instead, which makes
the code behave in the same (correct) way on both 32 and 64 bit
machines.
Reported-by: Linus Torvalds <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
lib/checksum.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
Arnd Bergmann <[email protected]> д?? 2009-12-04 03:14:08:
> This is the contents of the "next" branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git,
> as currently found in linux-next.
>
> Only two files are touched, most of the changes are bugfixes
> to the lib/checksum.c file that I introduced with the original
> asm-generic merge.
>
> If anything is missing here, please tell me.
>
Maybe you can add a __NR_set_thread_area define in asm-generic/unsitd.h
for tls used.
liqin
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
On Monday 07 December 2009, [email protected] wrote:
> Arnd Bergmann <[email protected]> д?? 2009-12-04 03:14:08:
>
> Maybe you can add a __NR_set_thread_area define in asm-generic/unsitd.h
> for tls used.
Yes, good point. I'll update the syscall list with this, and also check if more
syscalls have been addded.
Arnd <><
On Monday 07 December 2009, Arnd Bergmann wrote:
> On Monday 07 December 2009, [email protected] wrote:
> > Arnd Bergmann <[email protected]> д?? 2009-12-04 03:14:08:
> >
> > Maybe you can add a __NR_set_thread_area define in asm-generic/unsitd.h
> > for tls used.
>
> Yes, good point. I'll update the syscall list with this, and also check if more
> syscalls have been addded.
I have found now that sys_accept4 was missing. sys_set_thread_area however
is only defined on x86 and mips. Since you don't currently implement this
on score, maybe it would be more appropriate to handle it like the other
architectures do, rather than adding it to asm-generic/unistd.h?
Arnd
2009/12/10 Arnd Bergmann:
> On Monday 07 December 2009, Arnd Bergmann wrote:
>> On Monday 07 December 2009, [email protected] wrote:
>> > Arnd Bergmann <[email protected]> 写于 2009-12-04 03:14:08:
>> >
>> > Maybe you can add a __NR_set_thread_area define in asm-generic/unsitd.h
>> > for tls used.
>>
>> Yes, good point. I'll update the syscall list with this, and also check if more
>> syscalls have been addded.
>
> I have found now that sys_accept4 was missing. sys_set_thread_area however
> is only defined on x86 and mips. Since you don't currently implement this
> on score, maybe it would be more appropriate to handle it like the other
> architectures do, rather than adding it to asm-generic/unistd.h?
isnt the point of asm-generic/unistd.h to collect all common syscalls
? if there's syscalls that ideally should be handled by everyone but
currently doesnt, then it's easy to define it in the header but have
the actual entry.S leave it as a hole ...
or maybe i'm missing what's going on
-mike
On Thursday 10 December 2009, Mike Frysinger wrote:
> > I have found now that sys_accept4 was missing. sys_set_thread_area however
> > is only defined on x86 and mips. Since you don't currently implement this
> > on score, maybe it would be more appropriate to handle it like the other
> > architectures do, rather than adding it to asm-generic/unistd.h?
>
> isnt the point of asm-generic/unistd.h to collect all common syscalls
> ? if there's syscalls that ideally should be handled by everyone but
> currently doesnt, then it's easy to define it in the header but have
> the actual entry.S leave it as a hole ...
Well, sys_thread_area is not a common syscall but rather an exception.
I haven't looked at how glibc does implents TLS on different architectures,
but I think this is commonly done purely in user space without the
need for a syscall.
Arnd
On Thu, Dec 10, 2009 at 22:25, Arnd Bergmann <[email protected]> wrote:
> On Thursday 10 December 2009, Mike Frysinger wrote:
>> > I have found now that sys_accept4 was missing. sys_set_thread_area however
>> > is only defined on x86 and mips. Since you don't currently implement this
>> > on score, maybe it would be more appropriate to handle it like the other
>> > architectures do, rather than adding it to asm-generic/unistd.h?
>>
>> isnt the point of asm-generic/unistd.h to collect all common syscalls
>> ? if there's syscalls that ideally should be handled by everyone but
>> currently doesnt, then it's easy to define it in the header but have
>> the actual entry.S leave it as a hole ...
>
> Well, sys_thread_area is not a common syscall but rather an exception.
> I haven't looked at how glibc does implents TLS on different architectures,
> but I think this is commonly done purely in user space without the
> need for a syscall.
10+ architectures already have sys_[sg]et_thread_area of have reserved
entries for it.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Friday 11 December 2009, Geert Uytterhoeven wrote:
> 10+ architectures already have sys_[sg]et_thread_area of have reserved
> entries for it.
No, those are just the ones that blindly copied the unistd.h file from i386.
As I said, only i386 and mips implement it, and I would assume that this
is unlikely to change.
Arnd
On Fri, Dec 11, 2009 at 14:06, Arnd Bergmann <[email protected]> wrote:
> On Friday 11 December 2009, Geert Uytterhoeven wrote:
>> 10+ architectures already have sys_[sg]et_thread_area of have reserved
>> entries for it.
>
> No, those are just the ones that blindly copied the unistd.h file from i386.
> As I said, only i386 and mips implement it, and I would assume that this
> is unlikely to change.
M68k will have it in the near future...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds