Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+more\s+improvement\s+to\s+dev_alloc_name\s+\-\-\s+strnchr\s*$/: 14 ]

Total 14 documents matching your query.

1. [PATCH] more improvement to dev_alloc_name -- strnchr (score: 1)
Author: xxxxx>
Date: Mon, 19 Jan 2004 11:32:04 -0800
Okay, this patch avoids the loop if no wildcarding present, and keeps the same behaviour as original. It adds the string function strnchr to avoid searching past the maximum ifname size to find the f
/archives/netdev/2004-01/msg00398.html (12,642 bytes)

2. Re: [PATCH] more improvement to dev_alloc_name -- strnchr (score: 1)
Author: xxx>
Date: Mon, 19 Jan 2004 21:06:05 +0100
Please drop the ifdef. Don't want to encourage anybody to write strrchr() in assembly. -Andi
/archives/netdev/2004-01/msg00402.html (8,367 bytes)

3. Re: [PATCH] more improvement to dev_alloc_name -- strnchr (score: 1)
Author: @xxxxxxxxxx>
Date: Mon, 19 Jan 2004 13:07:44 -0800
I assume you mean strnchr not strrchr. Mainly just following the style of all the other string routines. What if gcc does it inline in some future version?
/archives/netdev/2004-01/msg00410.html (8,995 bytes)

4. Re: [PATCH] more improvement to dev_alloc_name -- strnchr (score: 1)
Author:
Date: Mon, 19 Jan 2004 22:15:15 +0100
Yep, strnchr. Not sure what it has to do with that. The #ifdef __HAVE_ARCH_* stuff is that architectures with crazy enough hackers can add assembly optimized functions if they want. But it clearly do
/archives/netdev/2004-01/msg00412.html (9,551 bytes)

5. Re: [PATCH] more improvement to dev_alloc_name -- strnchr (score: 1)
Author: xxxxxxxxxxxxxxx>
Date: Mon, 19 Jan 2004 13:44:29 -0800
Sometimes it is just used on a platform to force a call to the gcc builtin. I think it's perfectly reasonable what Stephen has done.
/archives/netdev/2004-01/msg00413.html (9,419 bytes)

6. Re: [PATCH] more improvement to dev_alloc_name -- strnchr (score: 1)
Author: inger@xxxxxxxx>
Date: Mon, 19 Jan 2004 15:27:48 -0800
Andi Kleen wrote: Not sure what it has to do with that. The #ifdef __HAVE_ARCH_* stuff is that architectures with crazy enough hackers can add assembly optimized functions if they want. But it clearl
/archives/netdev/2004-01/msg00416.html (9,362 bytes)

7. Re: [PATCH] more improvement to dev_alloc_name -- strnchr (score: 1)
Author: xxxxx>
Date: Mon, 19 Jan 2004 21:25:37 -0800
I'm deferring this until the next 2.6.x-pre starts up as well. Please resend at that time. Thanks Stephen.
/archives/netdev/2004-01/msg00434.html (8,651 bytes)

8. [PATCH] more improvement to dev_alloc_name -- strnchr (score: 1)
Author: Stephen Hemminger <shemminger@xxxxxxxx>
Date: Mon, 19 Jan 2004 11:32:04 -0800
Okay, this patch avoids the loop if no wildcarding present, and keeps the same behaviour as original. It adds the string function strnchr to avoid searching past the maximum ifname size to find the f
/archives/netdev/2004-01/msg01106.html (12,762 bytes)

9. Re: [PATCH] more improvement to dev_alloc_name -- strnchr (score: 1)
Author: Andi Kleen <ak@xxxxxxx>
Date: Mon, 19 Jan 2004 21:06:05 +0100
Please drop the ifdef. Don't want to encourage anybody to write strrchr() in assembly. -Andi
/archives/netdev/2004-01/msg01110.html (8,511 bytes)

10. Re: [PATCH] more improvement to dev_alloc_name -- strnchr (score: 1)
Author: Stephen Hemminger <shemminger@xxxxxxxx>
Date: Mon, 19 Jan 2004 13:07:44 -0800
I assume you mean strnchr not strrchr. Mainly just following the style of all the other string routines. What if gcc does it inline in some future version?
/archives/netdev/2004-01/msg01118.html (9,165 bytes)

11. Re: [PATCH] more improvement to dev_alloc_name -- strnchr (score: 1)
Author: Andi Kleen <ak@xxxxxxx>
Date: Mon, 19 Jan 2004 22:15:15 +0100
Yep, strnchr. Not sure what it has to do with that. The #ifdef __HAVE_ARCH_* stuff is that architectures with crazy enough hackers can add assembly optimized functions if they want. But it clearly do
/archives/netdev/2004-01/msg01120.html (9,771 bytes)

12. Re: [PATCH] more improvement to dev_alloc_name -- strnchr (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Mon, 19 Jan 2004 13:44:29 -0800
Sometimes it is just used on a platform to force a call to the gcc builtin. I think it's perfectly reasonable what Stephen has done.
/archives/netdev/2004-01/msg01121.html (9,665 bytes)

13. Re: [PATCH] more improvement to dev_alloc_name -- strnchr (score: 1)
Author: Alex Pankratov <ap@xxxxxxxxxxxxx>
Date: Mon, 19 Jan 2004 15:27:48 -0800
Not sure what it has to do with that. The #ifdef __HAVE_ARCH_* stuff is that architectures with crazy enough hackers can add assembly optimized functions if they want. But it clearly doesn't make any
/archives/netdev/2004-01/msg01124.html (9,644 bytes)

14. Re: [PATCH] more improvement to dev_alloc_name -- strnchr (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Mon, 19 Jan 2004 21:25:37 -0800
I'm deferring this until the next 2.6.x-pre starts up as well. Please resend at that time. Thanks Stephen.
/archives/netdev/2004-01/msg01142.html (8,795 bytes)


This search system is powered by Namazu