LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* coding style and re-inventing the wheel way too many times
@ 2006-12-21 11:48 Robert P. J. Day
  2007-01-23  1:11 ` [ot] " Oleg Verych
  0 siblings, 1 reply; 2+ messages in thread
From: Robert P. J. Day @ 2006-12-21 11:48 UTC (permalink / raw)
  To: Linux kernel mailing list


  this little project of mine of submitting the occasional code
"cleanup" has turned out to be way more daunting than i originally
thought, given how many source files insist on constantly re-inventing
the wheel.  consider a couple useful macros defined in
include/linux/kernel.h:

  #define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
  #define roundup(x, y) ((((x) + ((y) - 1)) / (y)) * (y))

  first, there's the obvious inconsistency in upper versus lower case,
and why no corresponding "round down" macro?  in any event, a rough
first attempt to see what could be re-worded using DIV_ROUND_UP (with,
admittedly, lots of false positives):

  $ grep -Er " ?+ ?([^ -]+) ?- ?1\) ?/ ?\1" *

ouch.  the same could be said for

  #define __ALIGN_MASK(x,mask)    (((x)+(mask))&~(mask))

where you can see possible replacements (again, just a hacky first
attempt with lots of bogus "hits" but still):

  $ grep -Er "\+.*(.*)\)* ?&~ ?\(*\1" *

and the list just goes on.

  one thing that might be useful would be to pull out the set of
generically useful macros into a separate header file, say
include/linux/cool_macros.h or something like that, and just put a
pointer to that header file from the CodingStyle file and strongly
encourage kernel programmers to read it and use it.

  the obvious set of macros for that file would be things related to:

  - rounding up and down
  - alignment and masking
  - array size
  - sizeof field
  - container_of
  - variants of min and max

and that sort of thing, and that header file could just be included
from kernel.h.

  in any event, even *i* am not going to go near this kind of cleanup,
but is there anything actually worth doing about it?  just curious.

rday

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [ot] Re: coding style and re-inventing the wheel way too many times
  2006-12-21 11:48 coding style and re-inventing the wheel way too many times Robert P. J. Day
@ 2007-01-23  1:11 ` Oleg Verych
  0 siblings, 0 replies; 2+ messages in thread
From: Oleg Verych @ 2007-01-23  1:11 UTC (permalink / raw)
  To: linux-kernel

On 2006-12-21, Robert P. J. Day wrote:
[]
>   in any event, even *i* am not going to go near this kind of cleanup,
> but is there anything actually worth doing about it?  just curious.

Moscow wasn't built at once...

You may notice as some others are doing little by little steps:
- source cleanups;
- right dependancy;
- headers includes;
- warnings elimination;
- code reading-analyzing (brainwashing, as for me;) and a few line
fixes everywhere.

I think there are members here, who doing things, like that for at
least two years.

You are trying to focus (mostly) on style and sense -- ok. And maybe it's
like to be alone within a crowd. Anyways, as long as you fill, that you
can do that, and patches are accepded, changes are *documented* its ok,
also. Sometimes it's stupid, worthless or something else. If so, then
find more interesting things to do, unless you are going to proof
something to somebody ;E.

Here's, as i can see, almost no place for emotions, only technical stuff
and everything not far from it. See, there isn't any reply on you
message, except this one. I think, because of that.

--
-o--=O`C
 #oo'L O
<___=E M


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2007-01-23  1:13 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-12-21 11:48 coding style and re-inventing the wheel way too many times Robert P. J. Day
2007-01-23  1:11 ` [ot] " Oleg Verych

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).