mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dave Airlie <airlied@linux.ie>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
	Michael Veeck <michael.veeck@gmx.net>,
	dri-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Remove DRM_ARRAY_SIZE
Date: Sun, 25 Sep 2005 09:30:24 +0100 (IST)	[thread overview]
Message-ID: <Pine.LNX.4.58.0509250923020.30376@skynet> (raw)
In-Reply-To: <1127636422.16288.1.camel@laptopd505.fenrus.org>


>
> ok so this brings the question: how does naming it DRM_ARRAY_SIZE make
> it more portable than naming it ARRAY_SIZE?
> If *BSD doesn't have ARRAY_SIZE, then surely naming it ARRAY_SIZE is
> easy for them to provide (after all they need to provide it already just
> called DRM_ARRAY_SIZE); if they have ARRAY_SIZE... then I assume it has
> the exact same semantics....
>

Yes I've heard this argument before, and it works for ARRAY_SIZE, but I'm
not sure it'll be okay for all macros we use, the other thing is I've no
idea what BSD or Solaris have or don't have, so if we just DRM_ most
things it makes it less likely we'll have a namespace clash later on ...

I'm not really caring either way though, I prefer to leave it as is unless
someone comes up with a really good reason as I'm lazy by nature, and I
don't think it really affects anyone either way... there are a lot worse
things in the drm that need looking at on my list before I start worrying
about naming macros...

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG


      reply	other threads:[~2005-09-25  8:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-24 21:11 Alexey Dobriyan
2005-09-24 23:56 ` Dave Airlie
2005-09-25  8:20   ` Arjan van de Ven
2005-09-25  8:30     ` Dave Airlie [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=Pine.LNX.4.58.0509250923020.30376@skynet \
    --to=airlied@linux.ie \
    --cc=adobriyan@gmail.com \
    --cc=arjan@infradead.org \
    --cc=dri-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.veeck@gmx.net \
    /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®