Re: fish names

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Feb 23, 2010 at 4:08 PM, Daniel Walker <dwalker@xxxxxxxxxxxxxx> wrote:
> I wanted to have the fish names discussion one more time. I think it's
> fine for Google to use those names internally, but we really want actual
> product names for the permanent kernel history.
>
> I know Pavel was the first to bring this up, and I do think it makes
> sense. I don't know if board-dream.c is the exact right name to have,
> but I think it's more along the right lines.
>
> I also think it makes sense to register real names for the
> machine_is_xxx names .. Since when your writing code it's easier to know
> what machine_is_nexusone() is vs. machine_is_mahimahi() ..
>
> I'm not suggesting you guys not use fish names altogether, I'm just
> concerned how this naming will impact the programmers outside Google who
> will be touching this code, and the general user population.

A big issue with the fish names is that final product names do not
always happen until late in the process (Nexus One was very far along
by the time it ended up being called Nexus One, for example).  It is
not at all uncommon for hardware products to have names that they're
known by which are not the mass market names, and also not uncommon
for these products to have a single board (trout, for example) which
is instantiated in a number of mass market products (Dream, G1, ADP1,
Revolution, etc).

The bootloaders for these products identify themselves using the
board/machine names, the userspace code sometimes locates features
based on those names, etc.

I still fail to understand why there's a problem with naming the
boards based on the names the development team for the device used.
That these names happen to be fish instead of a collection of numbers
and letters or some other codename seems unimportant.

This really feels like an needless hurdle ("we don't like your board
names") rather than a valid issue ("code does not compile", "code
fails checkpatch / has style violations", etc).

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux