Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+One\s+more\s+bugfix\s+for\s+xfs

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+One\s+more\s+bugfix\s+for\s+xfs_lowbit64\s*$/: 10 ]

Total 10 documents matching your query.

1. [PATCH] One more bugfix for xfs_lowbit64 (score: 1): Author: Andi Kleen <ak@xxxxxx>; Date: Fri, 22 Aug 2003 22:10:13 +0200; (mea culpa). The error return was broken too, it would return -2, not -1 for errors. Makes no difference in the callers, they never check for -1, but is still better to conform to the spec. Includes; /archives/xfs/2003-08/msg00261.html (7,546 bytes)
2. Re: [PATCH] One more bugfix for xfs_lowbit64 (score: 1): Author: Steve Lord <lord@xxxxxxx>; Date: 22 Aug 2003 16:02:13 -0500; Thanks Andi, this did have to happen one day after 1.3 didn't it. I will push it around various places, time for another push to Linus I guess. Steve -- Steve Lord voice: +1-651-683-3511 Principal En; /archives/xfs/2003-08/msg00263.html (8,091 bytes)
3. Re: [PATCH] One more bugfix for xfs_lowbit64 (score: 1): Author: Steve Lord <lord@xxxxxxx>; Date: 22 Aug 2003 16:09:53 -0500; You know, on second thoughts, are you sure about that? generic_ffs and man ffs seem to suggest otherwise. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lor; /archives/xfs/2003-08/msg00264.html (8,792 bytes)
4. Re: [PATCH] One more bugfix for xfs_lowbit64 (score: 1): Author: Andi Kleen <ak@xxxxxxxxxxxxx>; Date: Fri, 22 Aug 2003 23:48:30 +0200; ;-) I don't think it's very critical, From a quick look none of the callers ever pass in anything more than 32bits. It's used for the number of super block fields, which is < 32 and for some bmap, wh; /archives/xfs/2003-08/msg00265.html (8,591 bytes)
5. Re: [PATCH] One more bugfix for xfs_lowbit64 (score: 1): Author: Andi Kleen <ak@xxxxxxxxxxxxx>; Date: Fri, 22 Aug 2003 23:51:28 +0200; The i386 ffs does not agree with the man page. Manpage says 0 for no bit set, but i386 returns -1: static __inline__ int ffs(int x) { int r; __asm__("bsfl %1,%0\n\t" "jnz 1f\n\t" /* zero flag set whe; /archives/xfs/2003-08/msg00266.html (9,895 bytes)
6. [PATCH] One more bugfix for xfs_lowbit64 (score: 1): Author: Andi Kleen <ak@xxxxxx>; Date: Fri, 22 Aug 2003 22:10:13 +0200; (mea culpa). The error return was broken too, it would return -2, not -1 for errors. Makes no difference in the callers, they never check for -1, but is still better to conform to the spec. Includes; /archives/xfs/2003-08/msg00613.html (7,546 bytes)
7. Re: [PATCH] One more bugfix for xfs_lowbit64 (score: 1): Author: Steve Lord <lord@xxxxxxx>; Date: 22 Aug 2003 16:02:13 -0500; Thanks Andi, this did have to happen one day after 1.3 didn't it. I will push it around various places, time for another push to Linus I guess. Steve -- Steve Lord voice: +1-651-683-3511 Principal En; /archives/xfs/2003-08/msg00615.html (8,091 bytes)
8. Re: [PATCH] One more bugfix for xfs_lowbit64 (score: 1): Author: Steve Lord <lord@xxxxxxx>; Date: 22 Aug 2003 16:09:53 -0500; You know, on second thoughts, are you sure about that? generic_ffs and man ffs seem to suggest otherwise. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lor; /archives/xfs/2003-08/msg00616.html (8,792 bytes)
9. Re: [PATCH] One more bugfix for xfs_lowbit64 (score: 1): Author: Andi Kleen <ak@xxxxxxxxxxxxx>; Date: Fri, 22 Aug 2003 23:48:30 +0200; ;-) I don't think it's very critical, From a quick look none of the callers ever pass in anything more than 32bits. It's used for the number of super block fields, which is < 32 and for some bmap, wh; /archives/xfs/2003-08/msg00617.html (8,591 bytes)
10. Re: [PATCH] One more bugfix for xfs_lowbit64 (score: 1): Author: Andi Kleen <ak@xxxxxxxxxxxxx>; Date: Fri, 22 Aug 2003 23:51:28 +0200; The i386 ffs does not agree with the man page. Manpage says 0 for no bit set, but i386 returns -1: static __inline__ int ffs(int x) { int r; __asm__("bsfl %1,%0\n\t" "jnz 1f\n\t" /* zero flag set whe; /archives/xfs/2003-08/msg00618.html (9,895 bytes)

Current List: 1 - 10
Page: [1]