mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
To: David Miller <davem@davemloft.net>
Cc: florian@openwrt.org, peter@holik.at, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] usb driver for intellon based PLC like devolo dlan duo
Date: Sat, 18 Apr 2009 21:54:11 +0200 (CEST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0904182146220.14879@axis700.grange> (raw)
In-Reply-To: <20090418.015541.05303908.davem@davemloft.net>

On Sat, 18 Apr 2009, David Miller wrote:

> From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> Date: Fri, 17 Apr 2009 21:07:52 +0200 (CEST)
> 
> > FWIW, I think it's pretty common to name static functions in a .c file, 
> > which perform auxiliary function, not really specific to the context 
> > without the respective context-prefix.
> 
> I'll remember to think of you next time I run grep on the tree.

Thanks David, very nice of you:-)

Once an MMC driver has been submitted for a specific platform, which 
apparently has been derived from an MMC driver for a similar platform. And 
the submitter has preserved the function prefix... So most functions in 
the two drivers were called equally. Now that was bad, and I was the one 
to complain about it, no idea what was the end result with that driver 
though.

What I actually meant is that I don't necessarily consider it very 
inconvenient if different drivers have functions like reg_write() or 
whatever. I cannot think of many situations when this can be confusing. If 
you are working with that file and see a call to reg_write() you know 
where to look for it. If you have an Oops in that function - you just look 
one function up in the backtrace. One of the cases that might be difficult 
is if you have an Oops in such a function without a backtrace and it is in 
a module. Ok, in this case it might be difficult to find out what that 
was. Otherwise - why would you want to grep the sources for such a 
function?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

  reply	other threads:[~2009-04-18 19:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-17 14:10 Peter Holik
2009-04-17 14:32 ` Florian Fainelli
2009-04-17 19:07   ` Guennadi Liakhovetski
2009-04-18  8:55     ` David Miller
2009-04-18 19:54       ` Guennadi Liakhovetski [this message]
2009-04-19  4:15         ` David Miller
2009-04-19  4:24           ` David Miller
2009-04-19  8:32           ` Guennadi Liakhovetski
2009-04-19  8:35             ` David Miller
2009-04-18  6:48   ` Peter Holik
2009-04-18 10:22     ` Florian Fainelli
2009-04-18 13:42       ` Jon Smirl
2009-04-17 14:41 ` Oliver Neukum
2009-04-18  7:16   ` Peter Holik
2009-04-18  7:38     ` Oliver Neukum
2009-04-18  8:41       ` Peter Holik
2009-04-18  8:49         ` Oliver Neukum

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=Pine.LNX.4.64.0904182146220.14879@axis700.grange \
    --to=g.liakhovetski@gmx.de \
    --cc=davem@davemloft.net \
    --cc=florian@openwrt.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peter@holik.at \
    /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®