mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
To: Ingo Oeser <ioe-lkml@rameria.de>
Cc: "David Woodhouse" <dwmw2@infradead.org>,
	"Jesper Juhl" <jesper.juhl@gmail.com>,
	linux-kernel@vger.kernel.org,
	"Jochen Schäuble" <psionic@psionic.de>,
	"Thomas Gleixner" <tglx@linutronix.de>
Subject: Re: [PATCH] mtd: fix memory leaks in phram_setup
Date: Sun, 14 May 2006 22:07:40 +0200	[thread overview]
Message-ID: <20060514200740.GB20556@wohnheim.fh-wedel.de> (raw)
In-Reply-To: <200605141837.17318.ioe-lkml@rameria.de>

On Sun, 14 May 2006 18:37:15 +0200, Ingo Oeser wrote:
> On Sunday, 14. May 2006 15:21, Jörn Engel wrote:
> > 
> > Moving the printk into leaf functions?  My plan still is to collect a
> > bunch of those and put somewhere in lib/.  So maybe that's a bad idea.
> 
> That has been done already. One is kstrdup() from <linux/string.h>
> implementation in mm/util.c . So duplication can go.

Good point.

> parse_num32 is implemented as memparse() from 
> <linux/kernel.h> already, code is in lib/cmdline.c
> 
> It only misses the SI prefix stuff (kiBi and such).
> 
> Maybe SI units could be added to memparse() in
> lib/cmdline.c and all those reimplementations ripped of drivers/mtd/*/* ?

Not quite as simple.  My version is does two things.  First, it
accepts "ki" and second, it does not accept "k".  The latter is
important, because "k" means 1000, not 1024.

There are existing users that still use the historical interpretation,
so I guess we need both variants.

> > The macro sucks. 
> Agreed stronly! It is also against Documentation/CodingStyle, Chapter 11
> 
> No worries, error handling always clutters up our nice code. 
> 
> The only accepted way around this in Linux is "goto error_label", 
> so we can see the algorithm and read up on error handling at the 
> end of a function, after the algorithm.

Doesn't work here.  Every single error gives a different message.  Oh
well, let's go for the longer function.

Jörn

-- 
You can't tell where a program is going to spend its time. Bottlenecks
occur in surprising places, so don't try to second guess and put in a
speed hack until you've proven that's where the bottleneck is.
-- Rob Pike

      reply	other threads:[~2006-05-14 20:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-13 23:07 Jesper Juhl
2006-05-13 23:18 ` David Woodhouse
2006-05-13 23:34   ` Jesper Juhl
2006-05-13 23:40     ` David Woodhouse
2006-05-14  6:37       ` Jörn Engel
2006-05-14 11:03         ` David Woodhouse
2006-05-14 13:21           ` Jörn Engel
2006-05-14 16:37             ` Ingo Oeser
2006-05-14 20:07               ` 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=20060514200740.GB20556@wohnheim.fh-wedel.de \
    --to=joern@wohnheim.fh-wedel.de \
    --cc=dwmw2@infradead.org \
    --cc=ioe-lkml@rameria.de \
    --cc=jesper.juhl@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=psionic@psionic.de \
    --cc=tglx@linutronix.de \
    /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

all inboxes | Powered by JetHome®