All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Daney <ddaney@caviumnetworks.com>
To: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Cc: michael@ellerman.id.au, LKML <linux-kernel@vger.kernel.org>,
	linux-mips <linux-mips@linux-mips.org>,
	microblaze-uclinux@itee.uq.edu.au,
	devicetree-discuss@lists.ozlabs.org,
	linuxppc-dev list <linuxppc-dev@ozlabs.org>,
	sparclinux@vger.kernel.org
Subject: Re: Mega rename of device tree routines from of_*() to dt_*()
Date: Wed, 24 Nov 2010 09:18:06 -0800	[thread overview]
Message-ID: <4CED48CE.5060300@caviumnetworks.com> (raw)
In-Reply-To: <fa44e045-9600-4c46-939a-af246afab4f6@VA3EHSMHS019.ehs.local>

On 11/24/2010 09:02 AM, Stephen Neuendorffer wrote:
>
>
>> -----Original Message-----
>> From: linuxppc-dev-bounces+stephen=neuendorffer.name@lists.ozlabs.org [mailto:linuxppc-dev-
>> bounces+stephen=neuendorffer.name@lists.ozlabs.org] On Behalf Of Michael Ellerman
>> Sent: Wednesday, November 24, 2010 6:04 AM
>> To: LKML
>> Cc: linux-mips; microblaze-uclinux@itee.uq.edu.au; devicetree-discuss@lists.ozlabs.org; linuxppc-dev
>> list; sparclinux@vger.kernel.org
>> Subject: RFC: Mega rename of device tree routines from of_*() to dt_*()
>>
>> Hi all,
>>
>> There were some murmurings on IRC last week about renaming the of_*()
>> routines. I was procrastinating at the time and said I'd have a look at
>> it, so here I am.
>>
>> The thinking is that on many platforms that use the of_() routines
>> OpenFirmware is not involved at all, this is true even on many powerpc
>> platforms. Also for folks who don't know the OpenFirmware connection it
>> reads as "of", as in "a can of worms".
>>
>> Personally I'm a bit ambivalent about it, the OF name is a bit wrong so
>> it would be nice to get rid of, but it's a lot of churn.
>>
>> So I'm hoping people with either say "YES this is a great idea", or "NO
>> this is stupid".
>
> Personally, I think it's a great idea, if only because I stared long and hard
> at the code once upon a time trying to figure out what is really OF-related
> and what isn't.  It's somewhat clearer now that drivers/of has been factored
> out (although, shouldn't it be drivers/dt???)
>
> That said, it *is* alot of code churn.  If it's going to be done, I think it should be
> done in concert with fixing a bunch of the function names which don't really follow any
> sane naming convention, so that the backporting discontinuity only happens once.
>

Oh, you mean things like:

of_{,un}register_platform_driver vs. platform_driver_{,un}register

That one is particularly annoying to me.

David Daney

WARNING: multiple messages have this Message-ID (diff)
From: David Daney <ddaney@caviumnetworks.com>
To: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Cc: linux-mips <linux-mips@linux-mips.org>,
	microblaze-uclinux@itee.uq.edu.au,
	devicetree-discuss@lists.ozlabs.org,
	LKML <linux-kernel@vger.kernel.org>,
	linuxppc-dev list <linuxppc-dev@ozlabs.org>,
	sparclinux@vger.kernel.org
Subject: Re: Mega rename of device tree routines from of_*() to dt_*()
Date: Wed, 24 Nov 2010 09:18:06 -0800	[thread overview]
Message-ID: <4CED48CE.5060300@caviumnetworks.com> (raw)
In-Reply-To: <fa44e045-9600-4c46-939a-af246afab4f6@VA3EHSMHS019.ehs.local>

On 11/24/2010 09:02 AM, Stephen Neuendorffer wrote:
>
>
>> -----Original Message-----
>> From: linuxppc-dev-bounces+stephen=neuendorffer.name@lists.ozlabs.org [mailto:linuxppc-dev-
>> bounces+stephen=neuendorffer.name@lists.ozlabs.org] On Behalf Of Michael Ellerman
>> Sent: Wednesday, November 24, 2010 6:04 AM
>> To: LKML
>> Cc: linux-mips; microblaze-uclinux@itee.uq.edu.au; devicetree-discuss@lists.ozlabs.org; linuxppc-dev
>> list; sparclinux@vger.kernel.org
>> Subject: RFC: Mega rename of device tree routines from of_*() to dt_*()
>>
>> Hi all,
>>
>> There were some murmurings on IRC last week about renaming the of_*()
>> routines. I was procrastinating at the time and said I'd have a look at
>> it, so here I am.
>>
>> The thinking is that on many platforms that use the of_() routines
>> OpenFirmware is not involved at all, this is true even on many powerpc
>> platforms. Also for folks who don't know the OpenFirmware connection it
>> reads as "of", as in "a can of worms".
>>
>> Personally I'm a bit ambivalent about it, the OF name is a bit wrong so
>> it would be nice to get rid of, but it's a lot of churn.
>>
>> So I'm hoping people with either say "YES this is a great idea", or "NO
>> this is stupid".
>
> Personally, I think it's a great idea, if only because I stared long and hard
> at the code once upon a time trying to figure out what is really OF-related
> and what isn't.  It's somewhat clearer now that drivers/of has been factored
> out (although, shouldn't it be drivers/dt???)
>
> That said, it *is* alot of code churn.  If it's going to be done, I think it should be
> done in concert with fixing a bunch of the function names which don't really follow any
> sane naming convention, so that the backporting discontinuity only happens once.
>

Oh, you mean things like:

of_{,un}register_platform_driver vs. platform_driver_{,un}register

That one is particularly annoying to me.

David Daney

WARNING: multiple messages have this Message-ID (diff)
From: David Daney <ddaney@caviumnetworks.com>
To: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Cc: linux-mips <linux-mips@linux-mips.org>,
	microblaze-uclinux@itee.uq.edu.au,
	devicetree-discuss@lists.ozlabs.org,
	LKML <linux-kernel@vger.kernel.org>,
	linuxppc-dev list <linuxppc-dev@ozlabs.org>,
	sparclinux@vger.kernel.org
Subject: Re: Mega rename of device tree routines from of_*() to dt_*()
Date: Wed, 24 Nov 2010 17:18:06 +0000	[thread overview]
Message-ID: <4CED48CE.5060300@caviumnetworks.com> (raw)
In-Reply-To: <fa44e045-9600-4c46-939a-af246afab4f6@VA3EHSMHS019.ehs.local>

On 11/24/2010 09:02 AM, Stephen Neuendorffer wrote:
>
>
>> -----Original Message-----
>> From: linuxppc-dev-bounces+stephen=neuendorffer.name@lists.ozlabs.org [mailto:linuxppc-dev-
>> bounces+stephen=neuendorffer.name@lists.ozlabs.org] On Behalf Of Michael Ellerman
>> Sent: Wednesday, November 24, 2010 6:04 AM
>> To: LKML
>> Cc: linux-mips; microblaze-uclinux@itee.uq.edu.au; devicetree-discuss@lists.ozlabs.org; linuxppc-dev
>> list; sparclinux@vger.kernel.org
>> Subject: RFC: Mega rename of device tree routines from of_*() to dt_*()
>>
>> Hi all,
>>
>> There were some murmurings on IRC last week about renaming the of_*()
>> routines. I was procrastinating at the time and said I'd have a look at
>> it, so here I am.
>>
>> The thinking is that on many platforms that use the of_() routines
>> OpenFirmware is not involved at all, this is true even on many powerpc
>> platforms. Also for folks who don't know the OpenFirmware connection it
>> reads as "of", as in "a can of worms".
>>
>> Personally I'm a bit ambivalent about it, the OF name is a bit wrong so
>> it would be nice to get rid of, but it's a lot of churn.
>>
>> So I'm hoping people with either say "YES this is a great idea", or "NO
>> this is stupid".
>
> Personally, I think it's a great idea, if only because I stared long and hard
> at the code once upon a time trying to figure out what is really OF-related
> and what isn't.  It's somewhat clearer now that drivers/of has been factored
> out (although, shouldn't it be drivers/dt???)
>
> That said, it *is* alot of code churn.  If it's going to be done, I think it should be
> done in concert with fixing a bunch of the function names which don't really follow any
> sane naming convention, so that the backporting discontinuity only happens once.
>

Oh, you mean things like:

of_{,un}register_platform_driver vs. platform_driver_{,un}register

That one is particularly annoying to me.

David Daney

  reply	other threads:[~2010-11-24 17:18 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-24 14:03 RFC: Mega rename of device tree routines from of_*() to dt_*() Michael Ellerman
2010-11-24 14:03 ` Michael Ellerman
2010-11-24 14:03 ` Michael Ellerman
2010-11-24 14:03 ` Michael Ellerman
2010-11-24 15:44 ` Timur Tabi
2010-11-24 15:44   ` Timur Tabi
2010-11-24 15:44   ` Timur Tabi
2010-11-24 17:00 ` David Daney
2010-11-24 17:00   ` David Daney
2010-11-24 17:00   ` David Daney
2010-11-24 17:02 ` Stephen Neuendorffer
2010-11-24 17:02   ` Stephen Neuendorffer
2010-11-24 17:02   ` Stephen Neuendorffer
2010-11-24 17:02   ` Stephen Neuendorffer
2010-11-24 17:02   ` Stephen Neuendorffer
2010-11-24 17:02   ` Stephen Neuendorffer
2010-11-24 17:18   ` David Daney [this message]
2010-11-24 17:18     ` David Daney
2010-11-24 17:18     ` David Daney
2010-11-24 18:02     ` Grant Likely
2010-11-24 18:02       ` Grant Likely
2010-11-24 18:02       ` Grant Likely
2010-11-24 18:02       ` Grant Likely
2010-11-24 18:32     ` Stephen Neuendorffer
2010-11-24 18:32       ` Stephen Neuendorffer
2010-11-24 18:32       ` Stephen Neuendorffer
2010-11-24 18:32       ` Stephen Neuendorffer
2010-11-24 18:32       ` Stephen Neuendorffer
2010-11-24 18:32       ` Stephen Neuendorffer
2010-11-24 18:18 ` RFC: " David VomLehn
2010-11-24 18:18   ` David VomLehn
2010-11-24 18:18   ` David VomLehn
2010-11-24 18:18   ` David VomLehn
2010-11-25 13:34 ` Michael Ellerman
2010-11-25 13:34   ` Michael Ellerman
2010-11-25 13:34   ` Michael Ellerman
2010-11-25 14:01   ` Geert Uytterhoeven
2010-11-25 14:01     ` Geert Uytterhoeven
2010-11-25 14:01     ` Geert Uytterhoeven
2010-11-25 20:52     ` Benjamin Herrenschmidt
2010-11-25 20:52       ` Benjamin Herrenschmidt
2010-11-25 20:52       ` Benjamin Herrenschmidt
2010-11-25 16:17   ` Grant Likely
2010-11-25 16:17     ` Grant Likely
2010-11-25 16:17     ` Grant Likely
2010-11-26  3:15     ` Michael Ellerman
2010-11-26  3:15       ` Michael Ellerman
2010-11-26  3:15       ` Michael Ellerman
2010-11-26  4:42       ` Mitch Bradley
2010-11-26  4:42         ` Mitch Bradley
2010-11-26  4:42         ` Mitch Bradley
2010-11-26  4:42         ` Mitch Bradley
     [not found]         ` <4CEF3AB1.9060200-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2010-11-26  5:50           ` Michael Ellerman
2010-11-26  5:50             ` Michael Ellerman
2010-11-26  5:50             ` Michael Ellerman
2010-11-26  5:50             ` Michael Ellerman
2010-11-26  7:15             ` Grant Likely
2010-11-26  7:15               ` Grant Likely
2010-11-26  7:15               ` Grant Likely
2010-11-26  7:36             ` Mitch Bradley
2010-11-26  7:36               ` Mitch Bradley
2010-11-26  7:36               ` Mitch Bradley
2010-11-26  7:36               ` Mitch Bradley
2010-11-29  5:55   ` David Gibson
2010-11-29  5:55     ` David Gibson
2010-11-29  5:55     ` David Gibson
2010-11-29  6:07     ` Grant Likely
2010-11-29  6:07       ` Grant Likely
2010-11-29  6:07       ` Grant Likely

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=4CED48CE.5060300@caviumnetworks.com \
    --to=ddaney@caviumnetworks.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=michael@ellerman.id.au \
    --cc=microblaze-uclinux@itee.uq.edu.au \
    --cc=sparclinux@vger.kernel.org \
    --cc=stephen.neuendorffer@xilinx.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.