linux-kernel - Re: RFC - organize include/linux/kernel.h, add include/linux/logging.h

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 30 Nov 2007 10:04:31 -0800
From:	Joe Perches <joe@...ches.com>
To:	Alexey Dobriyan <adobriyan@...ru>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: RFC - organize include/linux/kernel.h, add
	include/linux/logging.h

On Fri, 2007-11-30 at 12:28 +0300, Alexey Dobriyan wrote:
> > kernel.h has become a bit disorganized over a long time.
> > Here's an attempt to clean it up a bit.
> > Something for everyone to like or dislike...
> You duplicate ALIGN macros all over the place.
> > This one used the ALIGN macro, but I'm not inclined to
> > figure out what it actually does right now, so copy
> > the old macro to this file and renames it.
> Which is not acceptable. Ditto for DIV_ROUND_UP.

There were 3 instances where macros were
used to specify an array size.  It seems
cleaner to use SEs and direct use of calculations
for those 3 instances. (ymmv)

What would you expect this to do?

        struct {
        	unsigned char ha[ALIGN(32,sizeof(unsigned long))];
        } foo;

A casual reading might suggest 0.

> And you somehow decided that putting statements on one line is more
> readable than on multiple lines -- typecheck and friends.

That appears to be the generally accepted coding style
for macros and statement expressions.

Whatever is agreed to is fine by me.

> Overall impression -- moving code just because you can.

Yes. It's definitely a cleanup.

I think creating a separate include for the printk related
defines and functions will be useful for possible future
improvements to logging.

There are many private logging definitions that could be
consolidated in generic way.  Things like:

	#define MY_PRINTK(fmt, arg) print(PFX fmt, ##arg)

cheers, Joe

-
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/