public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ftp.linux.org.uk>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: linux-kernel@vger.kernel.org, ralf@linux-mips.org
Subject: Re: [PATCH 02/17] mips: namespace pollution - mem_... -> __mem_... in io.h
Date: Wed, 8 Feb 2006 16:33:08 +0000	[thread overview]
Message-ID: <20060208163308.GI27946@ftp.linux.org.uk> (raw)
In-Reply-To: <Pine.LNX.4.64N.0602081615280.27639@blysk.ds.pg.gda.pl>

On Wed, Feb 08, 2006 at 04:21:45PM +0000, Maciej W. Rozycki wrote:
> On Wed, 8 Feb 2006, Al Viro wrote:
> 
> > >  Then the corresponding ones with no "mem_" prefix (these for the PCI I/O 
> > > port space) should be prefixed with "__" for consistency as well.
> > 
> > Huh???
> > 
> > Things like outb(), etc. *are* public; mem_... ones are not. 
> 
>  I mean if we rename e.g. mem_ioswabb() to __mem_ioswabb(), then we should 
> rename ioswabb() to __ioswabb() as well.  Sorry for not having been clear 
> enough, but I have assumed it is obvious.

In principle that would be nice, but...  Take a look at those macros.
We can do that, but it would mean #define readb __readb, etc.  Since
really nasty clashes are in mem_inb() et.al. (let's face it, coming up
with one of those is far more likely than using ioswabb() for driver-internal
purposes) I've stopped at that.  Can do a followup switching to __ioswab...
and adding defines compensating for changes in visible symbols, but IMO
that's a separate patch...

      reply	other threads:[~2006-02-08 16:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-08  7:10 [PATCH 02/17] mips: namespace pollution - mem_... -> __mem_... in io.h Al Viro
2006-02-08 11:01 ` Maciej W. Rozycki
2006-02-08 16:14   ` Al Viro
2006-02-08 16:21     ` Maciej W. Rozycki
2006-02-08 16:33       ` Al Viro [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=20060208163308.GI27946@ftp.linux.org.uk \
    --to=viro@ftp.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=macro@linux-mips.org \
    --cc=ralf@linux-mips.org \
    /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