linux-kernel - Re: [PATCH] SH/Dreamcast - add support for GD-Rom device

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 28 Dec 2007 12:41:36 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Mike Frysinger <vapier@...too.org>
Cc:	Joe Perches <joe@...ches.com>,
	Adrian McMenamin <adrian@...golddream.dyndns.info>,
	Jens Axboe <jens.axboe@...cle.com>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-sh <linux-sh@...r.kernel.org>
Subject: Re: [PATCH] SH/Dreamcast - add support for GD-Rom device

On Thu, Dec 27, 2007 at 07:49:01PM -0500, Mike Frysinger wrote:
> On Thursday 27 December 2007, Joe Perches wrote:
> > I also added a function gdrom_is_busy() to make a couple of tests
> > fit on a single line and perhaps easier to read.
> 
> i'd tend to agree it does make it easier to read, however you didnt make it 
> inline which means gcc may not inline it which means there's pointless 
> overhead of doing a function call.
> 
These days GCC is usually smart enough to automatically inline things
that are that small, it doesn't need to be explicitly labelled. If your
toolchain doesn't inline that gdrom_is_busy() implementation, get a
better toolchain.

> otherwise, arbitrary breaking on 80 cols actually makes the code harder to 
> read for no gain.

Hey now, some of us have no intention of giving up our 80x25 consoles,
not everyone buys in to this whole newfangled X thing. ;-)

More than 80 columns is generally fine so long as it's done so tastefully
rather than arbitrarily based on a larger console width. However, if it
can be split up cleanly for 80 columns, then it should be. ie, use common
sense, rather than blindly adhering to the whims of an anal-retentive
script.
--
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/