All of lore.kernel.org
 help / color / mirror / Atom feed
From: swetland@google.com (Brian Swetland)
To: linux-arm-kernel@lists.infradead.org
Subject: board/device file names, and machine names
Date: Tue, 2 Mar 2010 17:01:11 -0800	[thread overview]
Message-ID: <a55d774e1003021701r2dcadca2q395eba41f788af0f@mail.gmail.com> (raw)
In-Reply-To: <1267577534.8759.168.camel@c-dwalke-linux.qualcomm.com>

On Tue, Mar 2, 2010 at 4:52 PM, Daniel Walker <dwalker@codeaurora.org> wrote:
> On Tue, 2010-03-02 at 16:47 -0800, Tim Bird wrote:
>> On 03/02/2010 04:39 PM, Daniel Walker wrote:
>> > I'm ok with doing renames once all the code is merged .. That's always
>> > been one of the options with the Google code.
>> >
>> > However, we need some future direction .. If we do a rename later on
>> > with the older code, then we ideally want new code to be submitted with
>> > appropriate names..
>>
>> I'm not sure I understand. ?Are you suggesting that
>> code for new boards developed for Android phones be submitted
>> under the eventual product names? ?That's really not possible
>> if you want the code submitted before the product ships, because
>> the marketing department often finalizes a product name late
>> in the development cycle.
>
> No, It would be nice if the mass marketing name is known in advance,
> otherwise you have to use a code name .. Some phones however might have
> multiple code names..

As Tim points out, this is rarely the case -- marketing names are
quite often a late-binding decision.

As has been pointed out elsewhere it's not uncommon for devices to
ship under a number of different marketing names in different
environments.

Trying to optimize for matching the board name with the
most-recognized marketing name (something that may not be at all
possible to know until long after ship) seems like a lot of work for
little gain.

As Russell points out, one can provide guidance in the Kconfig
description and comments.

I continue to be somewhat amazed that this keeps coming up -- I'm
prepared to have people tell me my code sucks, or that we need to fix
style violations, or that they don't like the wakelock API, etc, but
it just blows my mind that somehow the big issue is that the board
files are named based on the development codenames of the projects
that they're for.  In my experience, this is common practice, and
based on glancing through mach-types, etc, does not seem uncommon even
in the ARM linux world.

Brian

  reply	other threads:[~2010-03-03  1:01 UTC|newest]

Thread overview: 31+ 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 [this message]
2010-03-03  3:52     ` Bill Gatliff
2010-03-03  8:42     ` Russell King - ARM Linux
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:18                 ` Pavel Machek
2010-03-03 10:19                 ` Russell King - ARM Linux
2010-03-03 10:19                   ` Russell King - ARM Linux
2010-03-03 14:24                   ` Pavel Machek
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=a55d774e1003021701r2dcadca2q395eba41f788af0f@mail.gmail.com \
    --to=swetland@google.com \
    --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 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.