RE: [E1000-devel] [PATCH 0/4] i40e: Neatening and object sizereductions

From: Nelson, Shannon
Date: Tue Sep 03 2013 - 21:00:18 EST


> -----Original Message-----
> From: Joe Perches [mailto:joe@xxxxxxxxxxx]
> Sent: Friday, August 30, 2013 4:06 PM
>
> Just some potential cleanings...

> i40e: Whitespace cleaning

Hmmm, we hadn't noticed the new experimental "--fix" option before. There are a lot of good suggestions there, but obviously it needs a lot of reading and tweaking before it can be used. There are cases here where function call parameters are adjusted to line up with the opening '(' but that pushes the parameter(s) beyond 80 columns - we're trying to stay within the 80 column line and checkpatch clean. Also, there are several where the first continued parameter line indent is changed but the next line or two are not.

We'll spend time going through these and try to take care of what makes sense.

> i40e: Add and use pf_<level>

We had considered this kind of macro awhile ago, but nixed it for a few different reasons, but primarily because it seems like yet-another-print-macro and not necessarily worth the effort.

> i40e: pf_<level> remove "%s: " ... __func__

We're beginning to remove many of the __func__ uses, so these prints are no longer all doing the __func__ thing. We originally had them there for early development and debugging and are currently removing them from the normal path messages.

> i40e: Convert pf_<level> macros to functions

Doesn't this create a problem with polluting the kernel namespace? These don't apply to any other driver. I suppose we could lessen the namespace problem with i40e_ prefix, but I'm still not sold on it. I suspect we can still get much of the text savings replacing the __func__ with __builtin_return_address(0) where needed, and remove them where no longer needed. Does that work for you?

> i40e: Fix 32 bit shift compilation warnings

Sure.

sln



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/