linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
To: Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua>
Cc: Yum Rayan <yum.rayan@gmail.com>,
	linux-kernel@vger.kernel.org, linux-pcmcia@lists.infradead.org,
	dahinds@users.sourceforge.net, rddunlap@osdl.org
Subject: Re: [PATCH linux-2.6.12-rc2-mm3] smc91c92_cs: Reduce stack usage in smc91c92_event()
Date: Tue, 26 Apr 2005 11:46:35 +0200	[thread overview]
Message-ID: <20050426094634.GA20971@wohnheim.fh-wedel.de> (raw)
In-Reply-To: <200504231821.31309.vda@port.imtp.ilyichevsk.odessa.ua>

On Sat, 23 April 2005 18:21:30 +0300, Denis Vlasenko wrote:
> On Saturday 23 April 2005 03:12, Jörn Engel wrote:
> 
> > > 1) struct is unnamed and local to function
> > > 2) Variables do not change their type, the just sit in local-> now.
> > >    I can just add 'local->' to each affected variable,
> > >    without "it was an object, now it is a pointer" changes.
> > >    No need to replace . with ->, remove &, etc.
> > 
> > I'd have proposed the same, before reading further down in the patch.
> > Basically, the driver is full of duplication, so the exact same struct
> > can be used several times.  Therefore, the downsides of your approach
> > seem to prevail.
> 
> What downsides? I must admit I do not understand your answer here.

1. Read the patch.  All of it.

2. Virtually the same identical variables are stuffed into the stack
frames of:
o mhz_mfc_config,
o mhz_setup,
o mot_setup,
o smc_setup,
o osi_setup and
o smc91c92_config.

That is six functions.  If it were just one, I would definitely agree
with you.  For two functions, well, it wouldn't really matter either
way.  But should six functions all copy the exact same struct six
different times instead of referencing a single globally defined one?
Naa, that's barely an advantage.

> Instead, I'd do it like I described in previous mail:

If you would actually like to do something, please provide further
patches to that driver.  It sucks.  It sucks so bad, that it's hardly
possible to change anything without improving it.  There are much
grosser things to clean up than the one we're discussing right now.

Jörn

-- 
He who knows others is wise.
He who knows himself is enlightened.
-- Lao Tsu

      parent reply	other threads:[~2005-04-26  9:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-21 22:02 [PATCH linux-2.6.12-rc2-mm3] smc91c92_cs: Reduce stack usage in smc91c92_event() Yum Rayan
2005-04-21 22:12 ` [PATCH linux-2.6.12-rc2-mm3] serial_cs: Reduce stack usage in serial_event() Yum Rayan
2005-04-22  8:22 ` [PATCH linux-2.6.12-rc2-mm3] smc91c92_cs: Reduce stack usage in smc91c92_event() Denis Vlasenko
2005-04-23  0:12   ` Jörn Engel
2005-04-23 15:21     ` Denis Vlasenko
2005-04-26  7:18       ` Yum Rayan
2005-04-26  9:46       ` Jörn Engel [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050426094634.GA20971@wohnheim.fh-wedel.de \
    --to=joern@wohnheim.fh-wedel.de \
    --cc=dahinds@users.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pcmcia@lists.infradead.org \
    --cc=rddunlap@osdl.org \
    --cc=vda@port.imtp.ilyichevsk.odessa.ua \
    --cc=yum.rayan@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).