board/device file names, and machine names

board/device file names, and machine names

[Daniel Walker]

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

Another example of this is,

arch/arm/mach-msm/board-trout.c

which in mainline we renamed to,

arch/arm/mach-msm/board-dream.c

Dream is actually a released name, so it seems to make more sense.
However, there are many other names we could have used.

machine_is_xx names have a similar kind of problem .. However, it's lot
easier to mainline a machine_is_xxx name ..

Any comments welcome, since this stuff is disputed and up in the air.
I'm sure many other projects have faced similar problems also.

Daniel

board/device file names, and machine names

[Brian Swetland]

On Tue, Mar 2, 2010 at 1:29 PM, Daniel Walker <dwalker@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:
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
3. This is the name the production userspace build for these phones
uses to identify the specific hardware and locate some features.
4. The Kconfig description provides a reasonable place to put more
expansive description of the various enduser visible product names.
5. My understanding has always been that MACH_* identifies a
particular board which may be instantiated in a number of products
6. I'm still unconvinced that a machine name like "mahimahi" is any
more or less confusing than any other common machine name for an ARM
board, which tend to be codenames, strange alphanumeric designators,
or combinations of the two.

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

Thanks,

Brian


>
> 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
>
> Another example of this is,
>
> arch/arm/mach-msm/board-trout.c
>
> which in mainline we renamed to,
>
> arch/arm/mach-msm/board-dream.c
>
> Dream is actually a released name, so it seems to make more sense.
> However, there are many other names we could have used.
>
> machine_is_xx names have a similar kind of problem .. However, it's lot
> easier to mainline a machine_is_xxx name ..
>
> Any comments welcome, since this stuff is disputed and up in the air.
> I'm sure many other projects have faced similar problems also.
>
> Daniel
>

board/device file names, and machine names

[Daniel Walker]

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 .. 
Which I don't think is what's going to happen.

> 5. My understanding has always been that MACH_* identifies a
> particular board which may be instantiated in a number of products
> 6. I'm still unconvinced that a machine name like "mahimahi" is any
> more or less confusing than any other common machine name for an ARM
> board, which tend to be codenames, strange alphanumeric designators,
> or combinations of the two.

It's like I said above, no one knows what mahimahi is. Eveyone knows
what nexus one is.

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

I want your code to go in, but I also want you to work with us.

I'm not insisting anything right now, I'm just getting a wider audience
to review the issue.

Daniel

board/device file names, and machine names

[Brian Swetland]

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

board/device file names, and machine names

[Russell King - ARM Linux]

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.

board/device file names, and machine names

[Daniel Walker]

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

board/device file names, and machine names

[Tim Bird]

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

board/device file names, and machine names

[Daniel Walker]

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

board/device file names, and machine names

[Brian Swetland]

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

board/device file names, and machine names

[Bill Gatliff]

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

board/device file names, and machine names

[Bill Gatliff]

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

board/device file names, and machine names

[Bill Gatliff]

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

> It's like I said above, no one knows what mahimahi is. Eveyone knows
> what nexus one is.
>   

But we don't really care about either specifically--- we just need to
know that they both refer to the same thing.



b.g.

-- 
Bill Gatliff
Embedded systems training and consulting
http://billgatliff.com
bgat at billgatliff.com

board/device file names, and machine names

[Bill Gatliff]

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

board/device file names, and machine names

[Brian Swetland]

On Tue, Mar 2, 2010 at 7:36 PM, Bill Gatliff <bgat@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.

Brian

board/device file names, and machine names

[Russell King - ARM Linux]

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.

board/device file names, and machine names

[Pavel Machek]

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

board/device file names, and machine names

[Russell King - ARM Linux]

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.

board/device file names, and machine names

[Pavel Machek]

> 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

board/device file names, and machine names

[Russell King - ARM Linux]

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.

Re: board/device file names, and machine names

[Pavel Machek]

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

board/device file names, and machine names

[Pavel Machek]

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

Re: board/device file names, and machine names

[Russell King - ARM Linux]

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.

board/device file names, and machine names

[Russell King - ARM Linux]

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.

Re: board/device file names, and machine names

[Pavel Machek]

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

board/device file names, and machine names

[Pavel Machek]

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

board/device file names, and machine names

[Daniel Walker]

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

board/device file names, and machine names

[Theodore Tso]

On Tue, Mar 2, 2010 at 5:56 PM, Brian Swetland <swetland@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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100303/eab4760b/attachment.htm>

board/device file names, and machine names

[Theodore Tso]

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@google.com> wrote:
> On Tue, Mar 2, 2010 at 5:56 PM, Brian Swetland <swetland@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
>
>
>

board/device file names, and machine names

[Russell King - ARM Linux]

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.

board/device file names, and machine names

[Nicolas Pitre]

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

board/device file names, and machine names

[Brian Swetland]

On Wed, Mar 3, 2010 at 2:08 PM, Nicolas Pitre <nico@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