[2736] in SIPB_Linux_Development
RedHat 6.0 sysname
daemon@ATHENA.MIT.EDU (Jeffrey Hutzelman)
Fri May 28 19:32:41 1999
Date: Fri, 28 May 1999 19:31:41 -0400
From: Jeffrey Hutzelman <jhutz+@cmu.edu>
To: linux-dev@MIT.EDU, cg2v+@andrew.cmu.edu, allbery+@cmu.edu,
vitroth+@cs.cmu.edu
Cc: jhutz+@cmu.edu, zumach+@transarc.com
I believe I've included all the people with any interest in this topic; if
you know of someone else, feel free to invite them to join in the fray.
MIT people can presumably read the discuss archive; others can get copies
from me of whatever they miss.
As has been discussed previously on linux-dev and amongst other people
reading this, a new sysname is needed for RedHat 6.0 systems, which use
glibc 2.1. This is necessary because programs built on RedHat 6.0 systems
will almost certainly not run on 5.2 systems. If we do not change the
sysname, then inevitably users will build things on 6.0 systems, and people
who haven't upgraded will lose.
I think it is in all of our interests (and those of our users) to use a
common sysname, so that people moving from one place to another don't lose,
and so there is less confusion about who has what mappings from sysname to
what the platform actually is. The purpose of this mail is to attempt to
come to some concensus on such a common sysname, so that those of us who
are working on RH6.0 support can get moving. In that vein, I would hope
that we can resolve this issue within a week or so.
I've heard several suggestions and theories on how to proceed. These break
down into the following basic categories:
A. Continue with the present series of small positive integers which change
each time there is a major change in the application environment and libc
version. This has the advantage of being consistent with previous
practice, but the number has no intrinsic meaning. Also, it seems that
the arla folks are using i386_linux{4,5,6} to destribe Linux systems with
libc 4, 5, and glibc 2.0, respectively. So, if we continue with this
scheme, we are likely to collide. Using method 'A' would result in a
sysname of 'i386_linux4'.
B. Follow Transarc's existing naming scheme. This method is good in
theory, because it is consistent with what most of us do on other
platforms, and will likely lead to better consistency with the outside
world. The chief problem with this method is that Transarc's current
product was built for and is supported on a glibc-2.0-based system
(RedHat 5.2). Thus, people in the rest of the world are likely to be
using 'i386_linux22' to refer to a RedHat 5.2 environment running
Linux 2.2.x kernels.
Unfortunately, it looks unlikely at this point that Transarc will do
a separate port with a new sysname for RedHat 6.0. Their existing
binaries will run on 6.0 systems, and there are no kernel differences
between RH6.0 and what Transarc already supports. Even if there is
such a release, it will likely not be soon, and it is difficult to
predict what the sysname would be. So, using method 'B' would have
to result in a sysname of 'i386_linux22'.
C. Follow Transarc's new naming scheme. Discussion with at least one
Transarc developer indicates that at some point in the future, they
will be moving to a three-part naming scheme, in order to address
problems caused by differing application environments. Under this
scheme, sysnames would be "hardware_os_user". Thus, the present
RedHat 5.2 environment would be something like "i386_linux22_glibc20",
and RedHat 6.0 would be "i386_linux22_glibc21". This is probably a
good long-term strategy, but again, it is hard to predict exactly
what the new name will be, if Transarc even does a release for 6.0.
Thus, it's unclear what the sysname would be under method 'C'.
D. Give up on distribution-independence, and derive the second part of
the sysname from the distribution. This has the advantage that it
describes the application environment much more completely, which
is what most of us actually use @sys for anyway. It also makes it
clear to people what distribution is actually supported, which may
be an advantage or a disadvantage, depending on your point of view.
Under method 'D', I would propose a sysname of 'i386_rh60'.
Those are all the methods I can think of from recent discussions;
I'm sure someone will come up with another. Of these, I personally
rank method 'A' as most desirable, followed by 'D', then 'B', and
finally 'C' as least desirable.
I think it's non-useful at this point to try to predict what Transarc
will do, since if we guess wrong, then we'll be just as incompatible
as if we had done some other, sensible thing. I also think it's
fairly important to avoid using any value that people would tend to
associate with some different, incompatible platform. Thus, using
something like 'i386_linux22' is undesirable because that is already
being used to mean 'RedHat 5.2 running a 2.2.x kernel', which is
different and incompatible.
-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
