[1529] in NetBSD-Development
Changing sysname and/or ATHENA_SYS?
daemon@ATHENA.MIT.EDU (Nathan J. Williams)
Sun Jan 11 20:39:27 1998
To: netbsd-dev@MIT.EDU, netbsd-afs@MIT.EDU
From: "Nathan J. Williams" <nathanw@MIT.EDU>
Date: Sun, 11 Jan 1998 20:39:07 EST
During the discussion of creating the 1.3 OS volume for the
NetBSD-Athena release, the topic of the sysname under NetBSD came
up. Unlike Transarc's AFS releases, our AFS client has kept the same
sysname <arch>_nbsd1 through several releases of NetBSD (1.0, 1.1, and
1.2, if my history is right). The ATHENA_SYS value, for those
NetBSD-Athena releases where it has existed, has been the same as the
AFS sysname.
While working on the development of the new NetBSD-Athena
release, I've come to think that the ATHENA_SYS value should be
different. A good deal of the Athena build system, which we're trying
to use for this release, depends on the HOSTTYPE value of the machine
(inbsd for NetBSD/i386, sun4 for Solaris/SPARC) for general OS
material (scripts and so on) and the ATHENA_SYS value for the more
specific decisions - scripts that are relative to specific versions of
the OS, binaries like AFS that depend on OS specificites, and so
on. Neither of these differentiate between NetBSD 1.0, 1.1, 1.2, or
1.3. Is hasn't been a problem so far, since using the Athena system is
new with the 1.3-based release, but I fear that it could be a big
problem when we want to do a 1.4-based release.
Perhaps more important is the locker problem. I've seen cases
with software in lockers where the software has been rebuilt on newer
versions of NetBSD (mostly 1.2 vs. -current, but there were some 1.1
vs. 1.2 problems) and the older systems have been unable to run the
new software. There have been several syscall changes between 1.2 and
1.3, and many changes in shared libraries as well: libc.so from 12.5
to 12.20; libedit from 0.0 to 1.0; libg++ from 3.0 to 4.0; libutil
from 3.2 to 4.2; the additions of lib{amu,bfd,ntp,ossaudio,wrap}. This
appears to be asking for disaster if locker maintainers have software
built under NetBSD 1.3 in the same directories that users of NetBSD
1.2 will use. This is the sort of thing that different values of
ATHENA_SYS, in conjunction with sane locker maintenance, is supposed
to avoid.
The downside of changing ATHENA_SYS is generally that it
requires locker maintainers to add links and/or recompile programs so
that users of the new systems can use programs in those lockers. If
we're lucky, though, we can use the ATHENA_SYS_PATH mechanisim to
allow users of the new system run binaries from lockers that haven't
been updated, avoiding most of the pain of running around to locker
maintainers getting them to create lots of links.
So I'm fairly convinced that we should change ATHENA_SYS for
NetBSD-Athena (i386) to "i386_nbsd13". If and when we build the same
software for other NetBSD architectures (I seem to be the only one
interested in doing this, although there are a handful of sparc, m68k,
and mips people who could use it), those ATHENA_SYS values will change
in a similar manner (but I may have more things to say about
"m68k8k_nbsd1").
Given that change, I think that it's also reasonable for the
AFS sysname to change. In fact, it seems to me that the AFS sysname
should track the OS closer than ATHENA_SYS might. However, I'm not
sure what the non-local implications of this would be, since I don't
know much about how other sites which run AFS under NetBSD make use of
sysname.
Comments?
- Nathan
