linux-kernel - coding style and re-inventing the wheel way too many times

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0612210614020.32046@localhost.localdomain>
Date:	Thu, 21 Dec 2006 06:48:45 -0500 (EST)
From:	"Robert P. J. Day" <rpjday@...dspring.com>
To:	Linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: coding style and re-inventing the wheel way too many times

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