linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: board/device file names, and machine names
Date: Wed, 3 Mar 2010 08:42:44 +0000	[thread overview]
Message-ID: <20100303084244.GD29715@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <1267576760.8759.164.camel@c-dwalke-linux.qualcomm.com>

On Tue, Mar 02, 2010 at 04:39:20PM -0800, Daniel Walker wrote:
> On Tue, 2010-03-02 at 23:51 +0000, Russell King - ARM Linux wrote:
> > On Tue, Mar 02, 2010 at 01:29:58PM -0800, Daniel Walker wrote:
> > > So one device has at least three names (more I'm sure),
> > > 
> > > 	Passion
> > > 	Mahimahi
> > > 	Nexus One
> > > 
> > > Google has most of the code support under board files with the name
> > > mahimahi.
> > 
> > I see no reason why the internal names can't be used in the code; just
> > make the configuration option texts user-friendly so that the common
> > names for the devices are used.
> 
> The internal names are usually available before the device also.
> However, in the case above there are multiple internal names. I
> personally think the naming matter, or making the tree more readable and
> cleaner .. What do you think, does the file naming even matter?

Not really.

> > A comment at the top of the file may also help.
> > 
> > As far as filenames go, let's keep them the same for now; we can rename
> > the filenames later once stuff is merged - while git can sort out
> > subsequent _merges_ with files renamed, but what it can't do is apply
> > patches on top of renamed files.  That's just something to be aware of
> > when chosing when to rename.
> 
> I'm ok with doing renames once all the code is merged .. That's always
> been one of the options with the Google code. 

It's the option of renames - and it's not something that should be
causing all this discussion.  Git can handle it well enough that it's
not a big problem if and when it happens.

> However, we need some future direction ..

Given the amount of discussion there's already been, I'm going to come
down hard on this issue to kill the discussion.

Stick with Google's existing naming for files and interally within files.
Put a comment in the files giving all the names.  Use the common name in
the Kconfig text, and either put the internal names in the help text or
in brackets in the main option text.


Don't like it?  I'm sure there's always going to be someone who doesn't
like whatever is decided upon, so get over it.  The important thing is
that the decision is made, and that there's no further dithering over
this issue.

  parent reply	other threads:[~2010-03-03  8:42 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-02 21:29 board/device file names, and machine names Daniel Walker
2010-03-02 22:56 ` Brian Swetland
2010-03-02 23:29   ` Daniel Walker
2010-03-02 23:38     ` Brian Swetland
2010-03-03  3:42     ` Bill Gatliff
2010-03-03  3:36   ` Bill Gatliff
2010-03-03  8:00     ` Brian Swetland
2010-03-03 19:08   ` Theodore Tso
2010-03-03 19:22     ` Theodore Tso
2010-03-03 19:24     ` Russell King - ARM Linux
2010-03-02 23:51 ` Russell King - ARM Linux
2010-03-03  0:39   ` Daniel Walker
2010-03-03  0:47     ` Tim Bird
2010-03-03  0:52       ` Daniel Walker
2010-03-03  1:01         ` Brian Swetland
2010-03-03  3:52     ` Bill Gatliff
2010-03-03  8:42     ` Russell King - ARM Linux [this message]
2010-03-03  9:17       ` Pavel Machek
2010-03-03  9:47         ` Russell King - ARM Linux
2010-03-03 10:00           ` Pavel Machek
2010-03-03 10:08             ` Russell King - ARM Linux
2010-03-03 10:18               ` Pavel Machek
2010-03-03 10:19                 ` Russell King - ARM Linux
2010-03-03 14:24                   ` Pavel Machek
2010-03-03 14:38       ` Daniel Walker
2010-03-03 22:08   ` Nicolas Pitre
2010-03-03 22:27     ` Brian Swetland
2010-03-03  3:25 ` Bill Gatliff

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=20100303084244.GD29715@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).