Fishy business [LWN.net]

By Jonathan Corbet
March 3, 2010

Many pixels have been expended about the presence of the Android code in the mainline kernel, or, more precisely, the lack thereof. There are many reasons for Android's absence, including the Android team's prioritization of upcoming handset releases over upstreaming the code and some strong technical disagreements over some of the Android code. For a while, it seemed that there might be yet another obstacle: source files named after fish.

Like most products, Android-based handsets go through a series of code names before they end up in the stores. Daniel Walker cited an example: an HTC handset which was named "Passion" by the manufacturer. When it got to Google for the Android work, they concluded that "Mahimahi" would be a good name for it. It's only when this device got to the final stages that it gained the "Nexus One" name. Apple's "dirty infringer" label came even later than that.

Daniel asked: which name should be used when bringing this code into the mainline kernel? The Google developers who wrote the code used the "mahimahi" name, so the source tree is full of files with names like board-mahimahi-audio.c; they sit alongside files named after trout, halibut, and swordfish. Daniel feels these names might be confusing; for this reason, board-trout.c became board-dream.c when it moved into the mainline. After all, very few G1/ADP1 users think that they are carrying trout in their pockets.

The problem, of course, is that this kind of renaming only makes life harder for people who are trying to move code between the mainline and Google's trees. Given the amount of impedance which already exists on this path, it doesn't seem like making things harder is called for. ARM maintainer Russell King came to that conclusion, decreeing:

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.

That would appear to close the discussion; the board-level Android code can keep its fishy names. Of course, that doesn't help if the code doesn't head toward the mainline anyway. The good news is that people have not given up, and work is being done to help make that happen. With luck, installing a mainline kernel on a swordfish will eventually be a straightforward task for anybody.

Index entries for this article
Kernel	Android

to post comments

Fishy business

Posted Mar 4, 2010 9:59 UTC (Thu) by djm (subscriber, #11651) [Link] (2 responses)

I demand the bikeshed be painted fuchsia.

Fishy business

Posted Mar 4, 2010 22:33 UTC (Thu) by dion (guest, #2764) [Link] (1 responses)

Thy will be done: http://fuchsia.bikeshed.org/

... Funny that I'll most likely be running into PHK tomorrow:)

Fishy business

Posted Mar 8, 2010 15:54 UTC (Mon) by Baylink (guest, #755) [Link]

Who did dat?

That's classic, classic stuff. :-)

In other news: please lets not ever have *any* arguments that internal project names appearing on or in files ever infringe on any trademarks in any way in any jurisdiction, cause it's Just Not So.

Keep a bit of character

Posted Mar 4, 2010 11:21 UTC (Thu) by epa (subscriber, #39769) [Link] (1 responses)

One of the pleasures of browsing the kernel source is to see the original (non-marketing) codenames for devices - 'Spock', the 'Happy Meal' and so on (sorry if these examples are ancient, it's been a long time since I have needed to build a kernel). Non-technical users are never going to see the source code anyway, so why worry about confusing them?

Keep a bit of character

Posted Mar 4, 2010 12:49 UTC (Thu) by Oddscurity (guest, #46851) [Link]

Exactly, I'm going to be happy when I can install a vanilla kernel on my seabass from now, the mutation can be loaded as a module and its temper can be set via debugfs.

Fishy business

Posted Mar 4, 2010 14:36 UTC (Thu) by nix (subscriber, #2304) [Link]

"The password is always 'swordfish'"? Oh no, the kernel is Marxist! ;}

Fishy business

Posted Mar 5, 2010 16:53 UTC (Fri) by jeremiah (subscriber, #1221) [Link] (13 responses)

After years of naming things after stuff, and then at some point do a lack of creativity or caring on
my part. I've come to the conclusion that code names are dumb. Yeah you can get exited about the
cool name and what not, but at some point in time your going to have to teach someone else what
it actually means, or your going to forget.

We used to name all of our servers after birds, this was fine when there were 3 or 4 of them. After
30+ this was no longer any fun, but a problem.

Sorry folks, just needed to rant.

Fishy business

Posted Mar 6, 2010 15:21 UTC (Sat) by bronson (subscriber, #4806) [Link] (12 responses)

You can get away with not using code names on small teams with a few deliverables.

On large teams, though, they're absolutely essential. Otherwise you spend entire paragraphs trying to figure out what everybody's talking about.

"Hey, was this change meant for the SSL-VPN product?"
"Which one, SMB or the enterprise?"
"SMB VPN doesn't exist anymore. Last week marketing renamed it to MyProtect."
"Ah. OK, was this change supposed to be in MyProtect?"
"Yeah, but not the hotfix. The main release."
"You know it was delayed for the URL rewrite feature?"
"Which, the hotfix or the main release?"
"The hotfix needed more attention so we rolled it into last week's staging. They're both in the main release now."
"Oh. OK, no, this is meant for the release after that."

vs.

"Hey, was this change meant for Sturgeon?"
"No, it's for Tilapia."

I speak from experience... *shudder*

Fishy business

Posted Mar 6, 2010 15:55 UTC (Sat) by jeremiah (subscriber, #1221) [Link] (11 responses)

I guess I should have been more clear in my rant...

I do agree hat everything needs a unique name, but I think it gets weird naming things after
other things, than it does naming them after what they do, or something like that.

example main file server used to be named 'penguin'
main firewall used to be named 'phoenix'

now there are more along the lines of 'firewall.x' and 'fileserver.x'

Perhaps this is more of a hardware/sysadmin issue than a software/development issue.

but take a look at fedora for example FC13 vs. 'fleshy penguin' or whatever. I personally like
names that mean something. I realize that marketing/ someone is going to frig with the name.
But why wouldn't you use an internal name with meaning?

example ssl-vpn-smb-v1, ssl-vpn-ent-v3, or whatever made since to the original developer.
I'm criticizing I'm just curious? I've had to come into to many projects where the LACK of a
meaningful internal name caused problems.

Fishy business

Posted Mar 6, 2010 16:22 UTC (Sat) by bronson (subscriber, #4806) [Link] (3 responses)

At a previous company, we ran the mail server, file server, and hosted the
administrator home directories on the same machine (the devs had bigger
home dirs and required less uptime so they were on a different box). What
name would you propose for this machine?

Now, let's say you move the mail server to a different host. Does the
hostname of the file server change too?

As for your product branch examples, ssl-vpn-smb-v1 is awfully tedious to
pronounce. Can you picture saying this to marketing execs in face-to-face
meetings?

Also, that seems pretty hard to remember. Is that smb-ssl-vpn-v1, or
vpn-smb-v1, or...? When typing it into an email, you'd probably have to
look it up to make sure you got it right.

I agree, it's easy for pinhead manager go overboard on code names and sink
his team in a sea of jargon. However, in my experience, refusing to use
code names at all ends up being equally painful.

Fishy business

Posted Mar 6, 2010 18:11 UTC (Sat) by jeremiah (subscriber, #1221) [Link] (2 responses)

Admittedly my internal product names are contrived, but as coders and what not, we are exports
at the TLA. So in daily use it would probably reduce to sls, and sle with some versioning tagged
on to the end. And as for say this to marketing, they can have there own external name, they
don't really need to know the internal one do they, since there going to be changing it all the
time anyway?

As for the servers, I've figured out where you and i differ. One of the things I do when wearing
my sysadmin hat as opposed to my developer hat, is PCI-DSS compliance for a payment
gateway. If you haven't done it, just know that it tedious to an extreme, but over all a good thing.
One of the things that it bring to the table, is that every service lives on a different server, to
minimize exposer from external threats. This is why we had an explosion in the number of
servers, but has enabled us to have a 1 to 1 service to server name based infrastructure.
Obviously no one is going to throw real hardware at a lot of these services, so most are handled
with virtualization. But each of those servers is named for its function as well which HBS-1 or
whatever. Combined with the Fibre channel LUN that one service/server or another is stored on.
Needless to say, we have a lot of infrastructure to manage, and it's all pool based. So the need
and the ability to name things according to service makes all of this manageable. Right now, I
manage 120+ servers, so it's all about manageability.

I guess it's an apples to oranges kinda thing, in that I would not run the mail server, file server,
and other things on the same box, but that's a luxury I have and other may not.

Fishy business

Posted Mar 8, 2010 15:58 UTC (Mon) by Baylink (guest, #755) [Link] (1 responses)

Speaking as an author of published research on this topic, Jeremiah (RFC 2100, to be precise), let me tell you that assigning to a machine a role based name is pretty much the Worst Imaginable Idea; any number of system administration textbooks (including the Purple Book and TPOSANA) can explain to you why in more detail than I have the time for right now.

You're perfectly welcome -- and in fact, encouraged -- to assign *DNS aliases* to them that are function/role based, but don't name the *machines* that.

Really.

Your replacement will thank you. ;-)

Fishy business

Posted Mar 8, 2010 18:28 UTC (Mon) by nix (subscriber, #2304) [Link]

In a past job, I had the great pleasure of sending the sysadmins a copy of
RFC2100 with the addition 'Learn, guys', when they decided, overnight, to
rename all our development systems from names like neptune and tabernacle
to nice memorable names like, if I can reconstruct one of
them, 'cddldsbgcorplr42-1' which encoded not just that this was a
development machine but the current name of the company and division and
the machine's *rack number* and location on its rack, with the declared
intention of changing this name whenever the company or division changed
names or the machine was reracked. (This was an improvement over their
previous edict, which was that all machines should be named after their IP
address. Even those getting their addresses from DHCP.)

(despite that name: this machine was not in Utah. 'lds' meant 'London
development centre' or something like that. Centre starts with an 's',
donchaknow.)

I found out later that said sysadmins didn't know what CNAMEs were. So
thanks for writing RFC2100: it started the painful process of imparting
Clue in this case, specifically that a machine can have many names.

Code names

Posted Mar 6, 2010 17:48 UTC (Sat) by giraffedata (guest, #1954) [Link] (6 responses)

Product code names used to be actual code names, not at all the same thing as naming a file server "penguin." A code name is designed to obscure the identity of the thing named.

I worked for IBM in the days when it was the leader in just about every product line it had. Competitors had to wait to see what IBM produced in order to know what to produce themselves as alternatives. IBM had a lot to lose from people finding out what projects were going on in the company, so it not only gave the projects code names, but changed those names every year or two to keep the outsiders guessing as internal documents leaked out.

It's my impression that few companies today benefit from keeping it a secret what they're working on (I mean what the goal is, not how the company is doing it). So the name of a project isn't code at all -- just a handle.

"Telephone handset" would not be an adequate name, since the company probably discusses lots of potential handset products other than Swordfish. "Dream" (what the users will eventually call it) is not really practical because you want to work on a project long before it's time to nail down the marketing strategy. So we're left with arbitrary names.

Now, to the topic of giving cute names to things like servers as opposed to naming them after their function: I struggled with this for a long time and eventually concluded that purely symbolic (content-free) names are the best way to go, because it gives me more flexibility. Renaming occasionally seems to be a bigger pain than the additional step of connecting the name with the thing named every time.

Code names

Posted Mar 6, 2010 18:27 UTC (Sat) by jeremiah (subscriber, #1221) [Link] (5 responses)

Maybe that's what's tickling the back of my head, that they aren't code names, but handles. And
I find handles non-informative. There just seems to be this urge out there for cuteness. I'm not
going to win any argument on the topic, but it's nice to know what peoples reasons are.

As for server name, you can see my other post, which basically says virtualization and pool based
hardware enables s to names servers after services, because we can slice and dice a lot more
easily than we used to.

I love being able upgrade a server, and make sure that the one service running on it works, and
cal it a day. Or to clone a server, upgrade the close, and drop it into place, and delete the
original, without having to point to some other ip address etc, and then run down everything
that's screwed up, because we used a different name. And the best over all is being able to build
a completely new infrastructure one server/service at a time, and dropping them into place w/o
having to change anything else, or even being able to roll back those changes by putting in/
bringing up the old server.

Code names

Posted Mar 6, 2010 19:50 UTC (Sat) by nix (subscriber, #2304) [Link] (4 responses)

Um, we could always do the slice-and-dice dance. You give the server a
meaningful, memorable name, and a role-based CNAME.

Code names

Posted Mar 6, 2010 21:59 UTC (Sat) by jeremiah (subscriber, #1221) [Link] (3 responses)

yeah, but why should the names be different? esp. when all of the iptables rules, and routing are
by ip, and not name. And what could be more meaningful than staffvpn.x or clientvpn.x or dns.x or
ntp.x, web.y, etc? By keeping the hostnames the same, automated searches against centralized
syslogs never have to be changed, dns never has to be changed. I'm curious what benefit you
would get from sliceing-and-diceing?

Code names

Posted Mar 8, 2010 16:04 UTC (Mon) by Baylink (guest, #755) [Link] (2 responses)

I would say "well, if we can't trust you to spell 'slicing' and 'dicing' properly, then..." but Jon wants us to be polite and respectful.

So I won't. :-)

Seriously, though: the issue has to do with replacing machines. There are often cases where you *cannot* have two machines existing in the world with the same name; most of these have to do with commercial licensing and other related stupidities.

If you're in such a regime, then you have no other real choice: the machine's "true name" has to be something new, different, and arbitrary -- the last because we've already established that it *can't* be the same name as the box it's replacing, which would then have to already have the functional name.

If you're replacing one outbound FTP server with another already configured server, you drop in the replacement, test it, and then "swing" the DNS CNAME to point to it (as telco guys used to swing jumpers on switch frames at 2am on Sundays on Big Switch Cuts), and you're done.

No muss, no fuss.

But AEleen, Evi, or Tom can probably explain this to you much better than I can. :-)

Code names

Posted Mar 8, 2010 17:37 UTC (Mon) by jeremiah (subscriber, #1221) [Link] (1 responses)

I never said I was trustworthy or that I could spell. Only that my life has been easier after moving
from code names to role based names, in a virtualized environment w/ one service per server.
Perhaps a hybrid approach would work best. With dns-1 and dns-2 as the hostnames and dns
as the CNAME? I realize that I'm beating a dead horse here, but let me continue anyway, since
this discussion will make me better at what I do, and therefor is more about understanding, than
arguing a point.

I have 40+ fibre channel LUNS, in most cases each LUN represents server/service. Each has a
number and WWN associated with it. I can map a WWN to a NAME which is represents a target
WWN. no DNS here. I also have FC switches which need mapping as well, zone names etc. I have
8 blades each of which has the ability to have 16 named LPARS. I also have wiki-documentation
for each complete mapping (IP,name,MAC,LUN,LPAR,VLAN,etc). The only thing that is constant in
this mess is the service that the machine is performing, and the IP address where it can be
found. Perhaps this is where the issue arises, in that in everyone else's experience, the IP
address and the Service are disconnected as well. When I bring a new replacement system online
I either copy it from a hardened clean copy, or the currently running copy, and run that LUN on a
different blade where I can test it etc. Then shut both the old and the new systems down, switch
the LUN mapping, and bring the new one up. This takes 2 - 5 min tops, which in my
environment, is fine. I don't have to change any DNS entries, logging, intrusion detection, etc. All
I have to do is change one entry on a fibre-channel controller.

After reading what I have written, maybe I am 'slicing' and 'dicing' but at a different level, than
CNAMES. Because my LUNS are just numbers that I can't really control. And If I could, they would
become DNS-1,DNS-2,DNS-3. I will say though, that when trying to diagnose a problem, it
helps immensely to have strict naming conventions on every piece and configuration.

Real machines vs. single-serving

Posted Mar 9, 2010 10:53 UTC (Tue) by dion (guest, #2764) [Link]

Something strange happens when you start using tons of virtual machines, in stead of maintaining every machine and putting more services on it, every virtual machine tends to become a wrapper around a single service, once that service is no longer needed the vm is simply deleted.

In the case of virtual machines that are created on demand and are sure to get nuked when they have served their purpose, I can certainly see a good reason for using function oriented names, because that name doesn't ever grow stale and once you have 17 similar servers doing pretty much the same thing then it becomes quite boring to come up with names and equally pointless.

I have no need to name single-use build slaves, so they are simply xp-1, xp-2, xp-3 and so on, no human typically interacts with the machines in their entire lifetime (about a day) before they are deleted and re-created from the master image.

For real, actual machines I still want an abstract name that have nothing at all to do with function and point function oriented CNAMEs at it as needed.