headers
Daniel Walker | 2 Mar 22:29

board/device file names, and machine names

Hi,

I was wondering if you (or the list) had any suggestions for proper
names to use in these two cases. Under mach-msm we have tons of devices
that could be added, and it can sometimes be hard to isolate a sane
name ..

I'll use the Nexus One device as an example .. HTC originally called
this device the HTC Passion prior to release.. Google named the same
device "mahimahi" prior to release .. Then finally it was released as
Nexus One .

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.

To me it makes a lot more sense to use a mass marketed name like "Nexus
One" .. Few people know what an HTC Passion is, and extremely few know
what "mahimahi" is.

Here is a link to mach-msm from Google's tree so you can see the naming
they use,

http://android.git.kernel.org/?p=kernel/msm.git;a=tree;f=arch/arm/mach-msm;h=f67bef98c885df15781d3122e3325f6164884118;hb=refs/heads/android-msm-2.6.29-nexusone
(Continue reading)

Permalink | Reply |
headers
Brian Swetland | 2 Mar 23:56
Picon
Favicon
Gravatar

Re: board/device file names, and machine names

On Tue, Mar 2, 2010 at 1:29 PM, Daniel Walker <dwalker <at> codeaurora.org> wrote:
>
> Hi,
>
> I was wondering if you (or the list) had any suggestions for proper
> names to use in these two cases. Under mach-msm we have tons of devices
> that could be added, and it can sometimes be hard to isolate a sane
> name ..
>
> I'll use the Nexus One device as an example .. HTC originally called
> this device the HTC Passion prior to release.. Google named the same
> device "mahimahi" prior to release .. Then finally it was released as
> Nexus One .
>
> 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.
>
> To me it makes a lot more sense to use a mass marketed name like "Nexus
> One" .. Few people know what an HTC Passion is, and extremely few know
> what "mahimahi" is.

We would, of course, prefer to keep the board named mahimahi for all
the reasons that have been mentioned in various previous discussions
around trout, etc:
(Continue reading)

Permalink | Reply |
headers
Daniel Walker | 3 Mar 00:29

Re: board/device file names, and machine names

On Tue, 2010-03-02 at 14:56 -0800, Brian Swetland wrote:

> 
> We would, of course, prefer to keep the board named mahimahi for all
> the reasons that have been mentioned in various previous discussions
> around trout, etc:
> 1. This was the name used during development for the platform.

Yeah, but HTC used a totally different name .. So why is your any more
important than their name?

Neither name has been used in mass marketing.

> 2. This is the name the bootloader uses and the production bootloader
> passes module parameters, etc under this name

Isn't this something Android specific tho? (you could reflash the
bootloader too can't you?)

> 3. This is the name the production userspace build for these phones
> uses to identify the specific hardware and locate some features.

How is this connected with the kernel? These devices can be reflashed
can't they?

> 4. The Kconfig description provides a reasonable place to put more
> expansive description of the various enduser visible product names.

Your not looking at it from the developers point of view .. Your
assuming your team does coding, and everyone else just uses the code ..
(Continue reading)

Permalink | Reply |
headers
Brian Swetland | 3 Mar 00:38
Picon
Favicon
Gravatar

Re: board/device file names, and machine names

On Tue, Mar 2, 2010 at 3:29 PM, Daniel Walker <dwalker <at> codeaurora.org> wrote:
>> This seems like an unforunate issue to bikeshed about, and by
>> insisting on renaming the board names, more hurdles are put up between
>> the (often competing, at least for our time) goals of "going to
>> mainline" and "maintaining an up to date tree that works on production
>> hardware without regression".
>
> This is really a classic kind of issue .. If you work with us (i.e. the
> community) , then your code goes into the kernel. If you ignore us, then
> your code usually doesn't go in ..

Alrighty then.

Brian
Permalink | Reply |
headers
Bill Gatliff | 3 Mar 04:42

Re: board/device file names, and machine names


> Yeah, but HTC used a totally different name .. So why is your any more
> important than their name?
>   

Well..... 'Cause they got there first.  :)

> Isn't this something Android specific tho? (you could reflash the
> bootloader too can't you?)
>   

Half the appeal of getting the Google/Qualcomm kernels into kernel.org,
at least for me, is being able to see the Very Same Code that's running
on my Nexus One phone.  If I have to reflash something to be able to use
the kernel.org kernels--- especially if the reflashing is just to
implement a name change--- then I lose the confidence that I'm looking
at the same thing that my phone is running.

> Your not looking at it from the developers point of view .. Your
> assuming your team does coding, and everyone else just uses the code .. 
> Which I don't think is what's going to happen.
>   

As a developer, I really don't care what the files are named, unless
those file names are the sole documentation available for the platform. 
As long as the various names for the hardware are documented
_somewhere_, then you've provided the information that I'm seeking.  In
that case, you could call the files board-q1.c, board-q2.c, and so on
and I'd be just as happy.
(Continue reading)

Permalink | Reply |
headers
Bill Gatliff | 3 Mar 04:36

Re: board/device file names, and machine names

Brian Swetland wrote:
> We would, of course, prefer to keep the board named mahimahi for all
> the reasons that have been mentioned in various previous discussions
> around trout, etc:
>   

Ooh, division in the camp.  :)

Actually, I'd like to change my previous answer.  In the interest of
getting code into kernel.org more quickly, I for one could live with
"mahimahi"--- so long as a comment in board-mahimahi.c provided the
"also-known-as" names.  Same for board-halibut.c, etc.

The point is to document the mapping between the various names
_somewhere_ within the kernel code itself.  Given that, LXR et. al can
help sort things out.  I'd prefer the mapping be done with filenames,
but mapping in comments is just about as good--- and probably more
flexible if a "mahimahi clone" ever appears: no need for another
filename, just add to the "also known as" comment.

b.g.

--

-- 
Bill Gatliff
Embedded systems training and consulting
http://billgatliff.com
bgat <at> billgatliff.com
Permalink | Reply |
headers
Brian Swetland | 3 Mar 09:00
Picon
Favicon
Gravatar

Re: board/device file names, and machine names

On Tue, Mar 2, 2010 at 7:36 PM, Bill Gatliff <bgat <at> billgatliff.com> wrote:
> Brian Swetland wrote:
>> We would, of course, prefer to keep the board named mahimahi for all
>> the reasons that have been mentioned in various previous discussions
>> around trout, etc:
>
> Ooh, division in the camp.  :)
>
> Actually, I'd like to change my previous answer.  In the interest of
> getting code into kernel.org more quickly, I for one could live with
> "mahimahi"--- so long as a comment in board-mahimahi.c provided the
> "also-known-as" names.  Same for board-halibut.c, etc.

halibut I'm happy to have Qualcomm rename -- the surf7201a is their
development platform after all.  The name was legacy from early days
before we were sure we could even refer to the board by its internal
name, etc.

Beyond all the other reasons I mentioned that we'd like to keep the
names for the projects that we wrote the code for (which includes some
devices manufactured by our friends at HTC, some of whom also
contributed kernel patches, thanks!), as we're trying to move this
code upstream we also have to maintain fully functional and working
trees internally (which we publish externally as well).

Avoiding disruptive renaming as stuff flows upstream makes it easier
for us to deal with the fact that we're not going to be able to drop all
our code in mainline all at once (much though that'd be convenient)
and to try to keep reducing the delta between our working branch(es)
and Linus's canonical linux kernel.
(Continue reading)

Permalink | Reply |
headers
Theodore Tso | 3 Mar 20:08
Picon
Favicon

Re: board/device file names, and machine names

On Tue, Mar 2, 2010 at 5:56 PM, Brian Swetland <swetland <at> google.com> wrote:


We would, of course, prefer to keep the board named mahimahi for all
the reasons that have been mentioned in various previous discussions
around trout, etc:
1. This was the name used during development for the platform.
2. This is the name the bootloader uses and the production bootloader
passes module parameters, etc under this name

This to me is the biggest thing to get right --- if there is deployed userspace which is using this name (mahimahi) in the bootloader to boot the machine, then changing this means that it adds a barrier to users who want to use the standard device userland, but who want to try testing their own kernel built from mainline.   Assuming that we eventually solve the rest of the issues, it would be a darned shame that just because the upstream community wanted to be "helpful" in renaming the device, someone wanting to build from upstream sources has a to apply a patch reversing the rename so that it will actually *work* on a standard Nexus One....

-- Ted


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel <at> lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Permalink | Reply |
headers
Theodore Tso | 3 Mar 20:22
Picon
Favicon

Re: board/device file names, and machine names

Trying again in plain text to avoid the
HTML-means-mail-is-automatically-SPAM filter.

-- Ted

On Wed, Mar 3, 2010 at 2:08 PM, Theodore Tso <tytso <at> google.com> wrote:
> On Tue, Mar 2, 2010 at 5:56 PM, Brian Swetland <swetland <at> google.com> wrote:
>>
>>
>> We would, of course, prefer to keep the board named mahimahi for all
>> the reasons that have been mentioned in various previous discussions
>> around trout, etc:
>> 1. This was the name used during development for the platform.
>> 2. This is the name the bootloader uses and the production bootloader
>> passes module parameters, etc under this name
>
> This to me is the biggest thing to get right --- if there is deployed
> userspace which is using this name (mahimahi) in the bootloader to boot the
> machine, then changing this means that it adds a barrier to users who want
> to use the standard device userland, but who want to try testing their own
> kernel built from mainline.   Assuming that we eventually solve the rest of
> the issues, it would be a darned shame that just because the upstream
> community wanted to be "helpful" in renaming the device, someone wanting to
> build from upstream sources has a to apply a patch reversing the rename so
> that it will actually *work* on a standard Nexus One....
>
> -- Ted
>
>
>
Permalink | Reply |
headers
Russell King - ARM Linux | 3 Mar 20:24
Picon

Re: board/device file names, and machine names

On Wed, Mar 03, 2010 at 02:08:31PM -0500, Theodore Tso wrote:
> This to me is the biggest thing to get right --- if there is deployed
> userspace which is using this name (mahimahi) in the bootloader to boot the
> machine, then changing this means that it adds a barrier to users who want
> to use the standard device userland, but who want to try testing their own
> kernel built from mainline.

Having a wide-ranging rename will be a major barrier to getting code
merged - especially if google intends to keep their internal naming.

It means every patch has to go through a renaming stage to be applied to
both trees - that's absolute madness.

There's still precious little to show in terms of progress on moving
this code towards the mainline tree - let's not put additional barriers
in the way.

Let's keep the current naming and arrange for informative comments in
files about the other names, and use the common name in the Kconfig -
that way it's obvious from the kernel configuration point of view what
is needed to be selected for a given platform, and it avoids the
problem of having effectively two code bases.
Permalink | Reply |
headers
Russell King - ARM Linux | 3 Mar 00:51
Picon

Re: board/device file names, and machine names

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.

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.
Permalink | Reply |
headers
Daniel Walker | 3 Mar 01:39

Re: board/device file names, and machine names

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?

> 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. 

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..

Daniel
Permalink | Reply |
headers
Tim Bird | 3 Mar 01:47
Picon

Re: board/device file names, and machine names

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.
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
Permalink | Reply |
headers
Daniel Walker | 3 Mar 01:52

Re: board/device file names, and machine names

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.. 

Daniel
Permalink | Reply |
headers
Brian Swetland | 3 Mar 02:01
Picon
Favicon
Gravatar

Re: board/device file names, and machine names

On Tue, Mar 2, 2010 at 4:52 PM, Daniel Walker <dwalker <at> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel <at> lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Permalink | Reply |
headers
Bill Gatliff | 3 Mar 04:52

Re: board/device file names, and machine names

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. 
>   

No.  Please, no.

The ideal outcome is that the kernel.org code becomes the canonical
source code for the platform, i.e. the difference between kernel.org and
Google/Qualcomm-internal code is nil.  You might not ever get there, but
you pretty much close off that opportunity entirely when you start
renaming stuff.

> 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..
>   

... which requires work from all interested parties: Qualcomm, Google,
and the community.  Far less likely to happen than, say, we all learn
that "mahimahi == Nexus One" because we read it in a comment somewhere.

b.g.

--

-- 
Bill Gatliff
Embedded systems training and consulting
http://billgatliff.com
bgat <at> billgatliff.com
Permalink | Reply |
headers
Russell King - ARM Linux | 3 Mar 09:42
Picon

Re: board/device file names, and machine names

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.
Permalink | Reply |
headers
Pavel Machek | 3 Mar 10:17
Picon

Re: board/device file names, and machine names

Hi!

> > 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.

Does not seem to be your decision. At least you should have cc-ed l-k.

									Pavel
--

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Permalink | Reply |
headers
Russell King - ARM Linux | 3 Mar 10:47
Picon

Re: board/device file names, and machine names

On Wed, Mar 03, 2010 at 10:17:28AM +0100, Pavel Machek wrote:
> Hi!
> 
> > > 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.
> 
> Does not seem to be your decision. At least you should have cc-ed l-k.

You really need to get a life.
Permalink | Reply |
headers
Pavel Machek | 3 Mar 11:00
Picon

Re: board/device file names, and machine names


> On Wed, Mar 03, 2010 at 10:17:28AM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > > > 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.
> > 
> > Does not seem to be your decision. At least you should have cc-ed l-k.
> 
> You really need to get a life.

And you really need to start to behave.

So... dwalker is maintainer of arch-msm, and does not like the
codenames. Then you come, and just because are maintainer of arm,
override the decision, without even notifying l-k?

									Pavel

--

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Permalink | Reply |
headers
Russell King - ARM Linux | 3 Mar 11:08
Picon

Re: board/device file names, and machine names

On Wed, Mar 03, 2010 at 11:00:23AM +0100, Pavel Machek wrote:
> 
> > On Wed, Mar 03, 2010 at 10:17:28AM +0100, Pavel Machek wrote:
> > > Hi!
> > > 
> > > > > 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.
> > > 
> > > Does not seem to be your decision. At least you should have cc-ed l-k.
> > 
> > You really need to get a life.
> 
> And you really need to start to behave.

No Pavel, it is YOU who need to behave.  You also need to go back to
school to learn to read.

> So... dwalker is maintainer of arch-msm, and does not like the
> codenames. Then you come, and just because are maintainer of arm,
> override the decision, without even notifying l-k?

So you don't think that Daniel, who was *explicitly* asking for my
suggestions and opinions, is entitled to a clear and straight answer?

Yes, go back and read the fucking thread properly Pavel.  Daniel
explicitly sent his messages TO me and ASKED me for this.

Daniel had my suggestions on my first reply in this thread, and his
follow up to that indicated he wanted something firmer - he wanted
a decision _FROM ME_ on which way to go.  That's precisely what he
got.

What you're actually trying to say is that you don't like me and you
certainly don't like me making any kind of decision.  Get over it, or
find some other project to infiltrate and infest with your idiotic
attitude.
Permalink | Reply |
headers
Pavel Machek | 3 Mar 11:18
Picon

Re: board/device file names, and machine names


Hi!

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

> > So... dwalker is maintainer of arch-msm, and does not like the
> > codenames. Then you come, and just because are maintainer of arm,
> > override the decision, without even notifying l-k?
> 
> So you don't think that Daniel, who was *explicitly* asking for my
> suggestions and opinions, is entitled to a clear and straight
> answer?

When someone asks for your suggestions, you can "go down hard on this
issue"?

Note that board_dream.c is already in the tree.

> Yes, go back and read the fucking thread properly Pavel.  Daniel
> explicitly sent his messages TO me and ASKED me for this.
> 
> Daniel had my suggestions on my first reply in this thread, and his
> follow up to that indicated he wanted something firmer - he wanted
> a decision _FROM ME_ on which way to go.  That's precisely what he
> got.
> 
> What you're actually trying to say is that you don't like me and you
> certainly don't like me making any kind of decision.  Get over it, or
> find some other project to infiltrate and infest with your idiotic
> attitude.

Stop putting words in my mouth. And start to behave.
									Pavel

--

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Permalink | Reply |
headers
Russell King - ARM Linux | 3 Mar 11:19
Picon

Re: board/device file names, and machine names

On Wed, Mar 03, 2010 at 11:18:00AM +0100, Pavel Machek wrote:
> 
> Hi!
> 
> > > > > > Given the amount of discussion there's already been, I'm going to come
> > > > > > down hard on this issue to kill the discussion.
> 
> > > So... dwalker is maintainer of arch-msm, and does not like the
> > > codenames. Then you come, and just because are maintainer of arm,
> > > override the decision, without even notifying l-k?
> > 
> > So you don't think that Daniel, who was *explicitly* asking for my
> > suggestions and opinions, is entitled to a clear and straight
> > answer?
> 
> When someone asks for your suggestions, you can "go down hard on this
> issue"?

It's clear that all you want to have is an argument.  This ends here.
Permalink | Reply |
headers
Pavel Machek | 3 Mar 15:24
Picon

Re: board/device file names, and machine names

On Wed 2010-03-03 10:19:57, Russell King - ARM Linux wrote:
> On Wed, Mar 03, 2010 at 11:18:00AM +0100, Pavel Machek wrote:
> > 
> > Hi!
> > 
> > > > > > > Given the amount of discussion there's already been, I'm going to come
> > > > > > > down hard on this issue to kill the discussion.
> > 
> > > > So... dwalker is maintainer of arch-msm, and does not like the
> > > > codenames. Then you come, and just because are maintainer of arm,
> > > > override the decision, without even notifying l-k?
> > > 
> > > So you don't think that Daniel, who was *explicitly* asking for my
> > > suggestions and opinions, is entitled to a clear and straight
> > > answer?
> > 
> > When someone asks for your suggestions, you can "go down hard on this
> > issue"?
> 
> It's clear that all you want to have is an argument.  This ends here.

It's clear that all I want is reasonable arm maintainer.
									Pavel
--

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Permalink | Reply |
headers
Daniel Walker | 3 Mar 15:38

Re: board/device file names, and machine names

On Wed, 2010-03-03 at 08:42 +0000, Russell King - ARM Linux wrote:

> 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.

Ok .. Thanks for the comments Russell.

Daniel
Permalink | Reply |
headers
Nicolas Pitre | 3 Mar 23:08

Re: board/device file names, and machine names

On Tue, 2 Mar 2010, 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.
> 
> 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.

IMHO using the internal name in the code is the most sensible thing to 
do.  Why? Because marketing people are a very emotional and influential 
bunch, and they often change their mind about naming and (re)branding.

Been there already.  And it also happened that marketing people just 
asked of us developers that the name of the files and functions in the 
source tree be changed to the marketing name du jour.  They especially 
don't want customers to ever notice that the new product out of the shop 
with all those revolutionary features and performances is in fact 
(technically speaking) just a minor revision of the previous product 
which can be supported by the same code as the previous product.  This 
has to be pushed back of course.

While the marketing names do change, normally the internal project names 
are more stable and more easily related to amongst developers.  And if 
there are many internal names, then the most widely used is the best.  
And if one name is already established in the source base then it is 
best to just keep it and not play renaming games unless really necessary 
(e.g. the old name is creating more confusion to _developers_ than if 
things were renamed).

The kernel tree is _not_ a medium for marketing campaign.  Those 
marketing names are best placed in the Kconfig text.  In this case I 
think that mahimahi for the board support is just fine.

Nicolas
Permalink | Reply |
headers
Brian Swetland | 3 Mar 23:27
Picon
Favicon
Gravatar

Re: board/device file names, and machine names

On Wed, Mar 3, 2010 at 2:08 PM, Nicolas Pitre <nico <at> fluxnic.net> wrote:
>
> IMHO using the internal name in the code is the most sensible thing to
> do.  Why? Because marketing people are a very emotional and influential
> bunch, and they often change their mind about naming and (re)branding.
>
> Been there already.  And it also happened that marketing people just
> asked of us developers that the name of the files and functions in the
> source tree be changed to the marketing name du jour.  They especially
> don't want customers to ever notice that the new product out of the shop
> with all those revolutionary features and performances is in fact
> (technically speaking) just a minor revision of the previous product
> which can be supported by the same code as the previous product.  This
> has to be pushed back of course.

This is a big motivation behind our "fish" names for boards -- they're
pretty unappetizing to the pr/marketing folks so they never get mixed
up with final product names and we can concentrate on making the
hardware work.  We can register board IDs far in advance and avoid
using "fake" machine IDs, yet not freak anybody out by revealing
significant product details.  Also, unlike numeric board names, they
tend to not imply one being better than the other, etc.

Brian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel <at> lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Permalink | Reply |
headers
Bill Gatliff | 3 Mar 04:25

Re: board/device file names, and machine names

Daniel Walker wrote:
> I was wondering if you (or the list) had any suggestions for proper
> names to use in these two cases. Under mach-msm we have tons of devices
> that could be added, and it can sometimes be hard to isolate a sane
> name ..
>   

Nobody outside of Google, HTC and/or Qualcomm will know the internal
names for these devices.

The majority of kernel.org developers don't work for Google, HTC and/or
Qualcomm.  The internal names are therefore meaningless to the majority
of kernel.org developers.

Internet searches by the internal platform names will turn up nothing
useful.

I say use the product release names.  But in board-nexusone.c add a
comment that says "this board is also known as: ...".

b.g.

--

-- 
Bill Gatliff
Embedded systems training and consulting
http://billgatliff.com
bgat <at> billgatliff.com
Permalink | Reply |

Gmane