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