| To: | Andi Kleen <ak@xxxxxxx> |
|---|---|
| Subject: | Re: [PATCH] more improvement to dev_alloc_name -- strnchr |
| From: | "David S. Miller" <davem@xxxxxxxxxx> |
| Date: | Mon, 19 Jan 2004 13:44:29 -0800 |
| Cc: | shemminger@xxxxxxxx, ap@xxxxxxxxxxxxx, netdev@xxxxxxxxxxx |
| In-reply-to: | <20040119221515.74629ac4.ak@xxxxxxx> |
| References: | <1074302619.40088e9bd44a6@xxxxxxxxxxxxxxx> <20040119113204.5913a8d6.shemminger@xxxxxxxx> <20040119210605.3cea32b0.ak@xxxxxxx> <20040119130744.324f582b.shemminger@xxxxxxxx> <20040119221515.74629ac4.ak@xxxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
On Mon, 19 Jan 2004 22:15:15 +0100 Andi Kleen <ak@xxxxxxx> wrote: > On Mon, 19 Jan 2004 13:07:44 -0800 > Stephen Hemminger <shemminger@xxxxxxxx> wrote: > > > What if gcc does it inline in some future version? > > 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 sense > with this function (in fact it doesn't make much sense with any string > function except memset/memcpy), so better not encourage it. 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. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH] more improvement to dev_alloc_name -- strnchr, Andi Kleen |
|---|---|
| Next by Date: | Re: PMTU issues due to TOS field manipulation (for DSCP), Kevin W. Rudd |
| Previous by Thread: | Re: [PATCH] more improvement to dev_alloc_name -- strnchr, Andi Kleen |
| Next by Thread: | Re: [PATCH] more improvement to dev_alloc_name -- strnchr, Alex Pankratov |
| Indexes: | [Date] [Thread] [Top] [All Lists] |