\documentstyle[11pt,timrom]{article}

\topmargin 0in
\headheight 0in			% no header
\oddsidemargin 0in
\evensidemargin 0in
\textwidth 6.50in
\textheight 8.50in
\footskip .4in

\begin{document}
\thispagestyle{empty}

\parindent 0in
\parskip \baselineskip

\begin{picture}(450,80)
\put (0,0){\special{psfile=/usr/athena/lib/owl.PS}}
\put (450,50){\makebox(0,0)[r] {\Large {\bf HP Evaluation}}}
\put (450,20){\makebox(0,0)[r] {\it {Richard P. Basch}}}
\put (450,0){\makebox(0,0)[r] {\it {\today}}}
\end{picture}
\vspace{1cm}

\section*{Introduction}
This document attempts to analyze the technical difficulties in porting
the Athena environment to the Hewlett-Packard Series 700 workstation,
running HP-UX, to function as a public-cluster workstation and Athena
server.  The time estimates presented here are based in terms of a
single person doing a port and is primarily figured by the cumulative
amount of time that people spent on various aspects of previous ports
(DEC/Ultrix 3.1 and IBM/AIX 3.1).  It is unrealistic to assume that a
single person can perform the port alone, as certain subsystems are best
left to the individual project teams to port to avoid a lot of wasted
effort (eg.  Andrew and AFS).

\section*{Evaluation}
The evaluation system tested was an HP 9000/720, 400MB internal disk.
Documentation was all but non-existant, except for a limited number of
online manual pages.  Documentation explaining installation procedures,
HP-UX administration, or the HP-UX development environment did not
accompany the evaluation units.

The evaluation, itself, was comprised of analyzing the AFS port that had
already been done for the HP and to attempt to port selected pieces of
software, such as {\tt named}.

\section*{Feasability}
The HP evaluation system proved to have a variant of SYSV UNIX with
certain BSD enhancements, specifically BSD sockets.  It also supports
AFS 3.1, long filenames, and certain BSD signal handling functions (eg.
sigvec).  In addition, the operating system claims to be POSIX 1003.1
and SVID 2 compliant, thereby reducing the amount of specialization that
needs to be put into a port to have this architecture integrated into
the Athena workstation environment.

\section*{Technical Difficulties}
\subsection*{BSD Compatibility}
Unlike with all previous architectures, HP-UX does not offer a BSD
compatibility library.  A port to the HP architecture will require that
the Athena software suite be properly ported to follow one of the
upcoming/new operating system standards (eg. POSIX 1003.1).  Only a
small fraction of that work had previously been done with the IBM
RISC/6000 AIX 3.1 port; the main change required to most applications
with the IBM port was the use of POSIX 1003.1 termios interface instead
of the BSD sgtty interface, certain changes in process handling, and
the use of the POSIX directory reading API.  Many BSD features were
still relied upon (eg. re-entrant signal handlers), which must now be
revisited and possibly converted to conform to POSIX, wherever possible.
It is estimated that only about 40\% of the POSIX conversion was done
during the IBM RISC/6000 port.  (2 months)

\subsection*{Bootstrapping}
One problem that has already been discovered is that the base utilities
used during a system build require significant work to function on the
HP architecture, specifically the {\tt install} program used.  Because
of the wide variety of {\tt install} programs shipped with the vendor
operating systems, it has become impossible for our build procedures to
accomodate all of those variants, or even the two most common variants
(SYSV and BSD).  It is expected that porting {\tt install, imake, and
makedepend} will take about 2 weeks (most of the time will be spent with
{\tt install}).

In addition, because much of the source tree is protected and it is
generally desirable to use a common source tree, a long time is spent in
bootstrapping in order to properly authenticate to the source tree and
non-local storage in which to do a proper build.  About 1.5 months is
spent in building enough libraries and utilities in which to properly
work (this includes the construction of the base utilities).  This
bootstrapping generally entails the building of the Kerberos libraries,
{\tt aklog}, and possibly {\tt synctree}.

\subsection*{User Interface}
As always, the introduction of a new architecture always has some user
interface differences.  Unlike our other platforms, the user interface
in HP-UX is almost completely SYSV based.  Users are accustomed to {\tt
ps aux} displaying their processes, but will quickly discover that such
BSD-like features are lacking in this operating system.  The port,
itself, is not affected significantly, unless we attempt to provide
certain command compatibility between the various platforms.  In the
past, this has always proven to be a controversial issue, and has
consumed some notable fraction of the time merely in discussions.

It is probably unwise to pursue an avenue where we attempt to provide
operating system heterogeneity, as this may adversely impact some third
party software that we may wish to import; it also complicates the idea
of layering Athena on top of the vendor operating system, increases our
dependence on the operating system source, and requires more development
resources to initially develop and to maintain over time.  It is also
the case that in industry, SYSV Unix is more prevalent, so it is to our
advantage to educate our intelligent user community about the various
flavors of Unix, rather than trying to provide partial compatibility.

\subsection*{Architecture Dependent ``Time-Sinks''}
{\bf Login} - Because Unix offers no standard system administration API,
the login interfaces must be adapted on each platform to adhere to the
local system's security paradigms.  In the case of HP-UX, this paradigm
is similar to BSD and Ultrix.  However, it is questionable as to whether
support for the HP integrated login/window system (hpvue) should be
supported by our login paradigm, especially for private workstation
owners.  The login paradigm has generally taken some effort to function
properly, including for console-mode logins.  (one month)

{\bf Printing} - In addition to the Athena {\tt lpr} command, we must
ensure that the standard print interfaces used by the system software
and third-party software are converted to support the Athena print
environment.  In the case of HP-UX, the utilities are the standard SYSV
spooling utilities ({\tt lp}) and must be replaced with versions that
use the Athena printing model.  (1.5 weeks)

{\bf Attach} - Because this program changes the machine's configuration
by mounting and unmounting filesystems, this client has proven to be
somewhat difficult to port.  Each operating system has its own semantics
for mounting and unmounting filesystems and as such, machine-specific
code must be designed and added for each operating system.  (3 weeks)

{\bf AFS and Andrew} - Both of these products have been previously
ported to the HP and only require that the Athena extensions be merged
and ported to the HP versions of these products.  Those with expertise
with these products will find the job easy to do, but others will have a
steep learning curve.  (3 weeks, assuming extensive prior working
experience)

{\bf Configuration} - {\tt mkserv}, {\tt machtype}, {\tt snmpd} and the
boot-time scripts must be crafted to work with the new architecture.
Because these configuration issues depend heavily on the various
operating system internals (including, but not limited to the
examination of kernel memory to determine configuration), there will be
little commonality between the HP versions of these utilities and their
counterparts on the existing platforms.  (2.5 months)

{\bf Installation} - This is perhaps one of the most time consuming
aspects of any port.  Our installation environment differs radically
from what every vendor ships; we require a simple, centrally-controlled,
no hand-customization installation procedure.  To accomodate such a
procedure, even in its crudest form, requires that the vendor's system
allows for network bootstrap installation, or floppy bootstrap in such a
mechanism that a network installation may be performed.  Insufficient
information is available at this time to make any assessment of the
situation.  The first generation media is not likely to be better than
the existing RISC/6000 installation media.  In order to create boot
media, it is expected that various questions will have to be asked of HP
developers, either directly or via newsgroups, and it is almost certain
that source code will be required to generate our own boot media.  (1.5
to 2 months)

\section*{Overall Assessment}
Between the initial port, which is expected to take about 9-10 man
months, and the debugging during the testing stage, it is expected that
the HP port will cost about 11 man-months of development effort.
Because certains aspects of the port will always be costly (initial
bootstrapping and the architecture-dependent time-sinks), it is unlikely
that any port will ever cost less than 6 man-months.

A complete Athena port requires an examination of approximately 30,000
source files, and modifying approximately 5\% of these files (as time
goes on, this number is expected to decrease as our source tree becomes
more compliant with the upcoming standards).  Thus, the complexity is
greatly simplified if we choose only to port selected services to a
given architecture, and is even more simplified if those services are
merely client programs that do not modify or examine the machine's
configuration in anyway.

The following components could probably be developed in three months.
The problem with delivering such a product is that little development
has been invested in delivering a layered Athena product.  As such, no
estimate on completion can be given, without some basic understanding of
the mechanism by which we will deliver layered software.

{\tt \begin{verbatim}
Kerberos clients: kdestroy, kinit, klist, kpasswd
Hesiod clients: named, hesinfo
Zephyr clients: zwrite, znol, zlocate, ...
Discuss clients: discuss, dsc_setup, crmtgs, mkds, rmds
Moira clients: moira, listmaint, mailmaint, blanche
attach
lpr, lprm, lpq, lpquota
olc, olcr
\end{verbatim}}

\section*{Source Code Requirements}
Source code is useful, if not essential, for developing most of the
architecture-dependent pieces of the port, and for the installation
procedures, it is likely to be a requirement.

\end{document}