I have spoken from experience rather than from the spec.
Here I am scratching my head trying to figure out why Willem and Alan
are confusing 'hostid' with gethostid(), and lo and behold
I see cross reference when I bother to read the man pages. Sorry.
HOWEVER:
hostid != gethostid
I submit to you that the inspriation for 'hostid' on Linux
comes from 'hostid' on Solaris, which does NOT report something
tied to the IP address (as gethostid() would). I further submit
that 'hostid' on Linux does not necessarily report something
tied to the IP address but rather something it gets from /etc/hostid.
The CPU serial number in Sun land appears to be a 32-bit value.
Although Solaris' man pages (as Linux's) cross reference
'hostid' to gethostid(), the behaviour of the former
clearly indicates that it is not related to a network address
but rather to the CPU identifier.
Combine the flag that says "this is a Sun" with that bit string
and you have something that we hope we can say is unique.
The CPU serial number in IBM (zSeries) land is a 64-bit value
of which we only use 24 or even 20 bits as the identification.
Combine the 64-bit string with "this is an IBM mainframe"
and you have something that we hope we can say is unique.
Alan said:
> There's really no value to hostid or gethostid() because the result is
> not well-defined across platforms. ...
Ignoring the gethostid() reference, I say there *is* value in
'hostid' if what you're after is a unique identifier AND IFF
1) you retool it to report something derived from the CPU ID, and
2) you take into account the vendor (to avoid collisions where
both Sun and IBM happen to report CPU ID "12345").
> And I agree with Alan Cox that things like
> get-me-a-world-unique-64-bit-number() should be obtained by something
> other than the gethostid().
I too agree with that.
> Make such a call part of the POSIX standard
> or something. It's not a networking thing. gethostid(), for better or
> worse, is.
Right. gethostid() is a networking thing. 'hostid' is not.
Dead horse?
