Hi!
BTW... All the time I'm programming in kernel, I use printf(), and
when hacking userspace, I use printk().
Nasty.
Given that printf() and printk() have exactly the same behaviour,
could we allow printf() in kernel? Now... printk()s are usually
removed before merging the driver, so code will
On Fri, Dec 05 2014, Joe Perches j...@perches.com wrote:
On Fri, 2014-12-05 at 08:18 +0100, Julia Lawall wrote:
On Thu, 4 Dec 2014, Joe Perches wrote:
Yes, by using python/ocaml:
@r@
char [] c;
position p;
identifier f;
@@
f(...,c@p,...)
@script:ocaml@
c r.c;
p r.p;
@@
On Fri, 2014-12-05 at 07:24 -0800, Joe Perches wrote:
My preference would be to eventually eliminate printk
altogether but I don't see a real problem adding
#define printf printk
to include/linux/printk.h
but
(bah, bad touchpad)
but I'm not going to write or ack that patch.
On Fri, 5 Dec 2014, Rasmus Villemoes wrote:
On Fri, Dec 05 2014, Joe Perches j...@perches.com wrote:
On Fri, 2014-12-05 at 08:18 +0100, Julia Lawall wrote:
On Thu, 4 Dec 2014, Joe Perches wrote:
Yes, by using python/ocaml:
@r@
char [] c;
position p;
identifier f;
@@
On Fri, 2014-12-05 at 16:14 +0100, Rasmus Villemoes wrote:
Hardcoding the function name in a literal string also makes typos (or
copy-pastos) possible. I extended Julia's code to allow a small edit
distance. Requires the Levenshtein python module (on debian, apt-get
install
