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: <20090729173231.012d0b89@skybase>
Date:	Wed, 29 Jul 2009 17:32:31 +0200
From:	Martin Schwidefsky <schwidefsky@...ibm.com>
To:	dwalker@...o99.com
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	john stultz <johnstul@...ibm.com>
Subject: Re: [RFC][patch 02/12] remove clocksource inline functions

On Wed, 29 Jul 2009 08:57:13 -0600
dwalker@...o99.com wrote:

> On Wed, 2009-07-29 at 16:44 +0200, Martin Schwidefsky wrote:
> > On Wed, 29 Jul 2009 08:15:19 -0600
> > dwalker@...o99.com wrote:
> > 
> > > > Remove clocksource_read, clocksource_enable and clocksource_disable
> > > > inline functions. No functional change.
> > > > 
> > > 
> > > Your still not really explaining this one, is this suppose to be
> > > cleaner? Or is this related to some other part of your clean up?
> > 
> > The only one of the three inline functions that is a bit more
> > complicated is clocksource_enable() because of the mult_orig logic. But
> > that goes away with a later patch. The function aren't accessors either,
> > they are used exclusively by the timekeeping code. In short, they are
> > useless, don't you think?
> 
> Above is what should go in your patch description .. 

Ok, sounds reasonable.
 
> The reason that I'm not totally into this one is cause these inlines
> help to document to the code..
> 
> If you have ,
> 
> struct clocksource cs;
> 
> then several lines later you have
> 
> cs->read(); 
> 
> vs,
> 
> clocksource_read(cs);
> 
> The later is completely clear, and the former isn't.. Instead of "cs"
> you could pick any obscure name, and read() isn't exactly unique.. So
> really any function in the clocksource structure has the potential for a
> helper, and the inlines don't really cost anything ..

Hmm, you have an object of type struct clocksource and you do
cs->read(cs). If that is not clear enough then I don't know what is. We
do that all over the place in the linux kernel. And I personally find
these useless wrappers rather annoying. I don't like to have to jump to
another place to find out that it just calls the read function of the
object.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ