Short version:My inclination is to simply better document that hostid is an interface without clear semantics which exists for compatability with legacy systems and should not be used in new applications.
Longer version:What is the reason for wanting to use hostid? Historically this sort of interface was most often used for software licensing and other such applications which wanted to tie something to a particular piece of hardware. On the proprietary hardware, the vendors would encode a serial number which was nicely suited to that purpose. On linux, we don't have such a hardware serial because we don't control the hardware, and we don't have a real strong desire to facilitate software licensing schemes. (If someone wants to cobble one together, fine, but we're not going to do the work for it.) Intel tried to implement cpuids for this purpose, and it flopped; we're unlikely to get further than they did. Any scheme that relies on a cookie isn't going to provide that "tied to the hardware" guarantee (a guarantee which is increasingly meaningless in a VM world, anyway). And, dbus already went and reinvented that wheel--does it make any sense to try to re-reinvent that wheel? You still won't be able to rely on hostid having a useful value, because it will be installation-dependent (unlike dbus, which got to define the semantics from the ground up). You'll basically have an interface which on some systems has a great semantic, and on others does not, so the documentation will have to say exactly what it should say now: "use something else".
So should we just get rid of it? Doing so would probably break some ancient stupid script somewhere, to save 40k. And it's within the realm of possibility that someone, within a particular environment, is actually managing the hostids to do something useful, so we shouldn't break that.
Mike Stone
signature.asc
Description: Digital signature
