Ty Sarna <tsarna@endicor.com> wrote:
> Bad reasoning.  The COMPAT code _could_ always emulate the necessary
> kernel kludges of those OSes even while not supporting shared libraries
> itself.  It just so happens that it doesn't in the SunOS case (I don't
> know about HPUX).
   
   This is not bad reasoning. I was originally thinking that the COMPAT
code does emulate the various quirks of SunOS and HP-UX kernels, but when
no special kernel support is required for shared libs (except mmap(2) which
as you say is always present in 4.4BSD) this becomes unnecessary and
achieving compatibility becomes much easier. My reasoning was that in the
world of non-profit software the easiest approach is almost always the one
actually used.
   
   I'm now getting a clearer picture of native OS emulation in 4.4BSD. The
pmax port doesn't have to worry about shared libs for Ultrix compatibility,
since Ultrix doesn't use them. The sparc port doesn't have to worry about
shared libs for SunOS compatibility, since all that's required is mmap(2)
which as you say is always present. HP-UX emulation in the hp300 port is
probably more difficult. I was surprised that it's possible in the first
place, since HP-UX is East Coast (System V). I'm sure that its disk
partitioning scheme, its filesystem format, and the way it handles
peripherals are completely different from and incompatible with BSD. I was
thinking the same about the executable format, but apparently it's a.out
after all. Also I think that the pmax and sparc ports haven't existed
before 4.4BSD, so probably the new VM (which I assume is responsible for
mmap(2)) has already been there when they were born. The hp300 port, on the
other hand, originates from HPBSD 1.x (developed at the University of
Utah). HPBSD 1.x predates 4.3BSD-Reno and is 4.3BSD vintage. Some parts of
the Reno movement (the hp300 port and the NFS support) originate from it,
and some other parts (the new VM, for instance) were later developed
together by CSRG and the U of U guys who have written HPBSD. The HP-UX
emulation in the hp300 port was probably necessary for the development of
the port itself, so I can bet that it exists in the 4.3BSD-vintage HPBSD
1.x. Being able to emulate HP-UX on a 4.3BSD-vintage OS implies that
probably the shared lib mechanism is something other than mmap(2) in HP-UX.
But of course this is just guesswork.
   
> In the COMPAT_LINUX case, code to emulate kernel
> involvement in shared libraries _is_ included, because that's how Linux
> shared a.out binaries work.
   
   Since fortunately Linux is not the native OS for any platform, Berkeley
UNIX(R) developers didn't have to worry about emulating it.
   
> Perhaps it's due to a switch from [ON]MAGIC to ZMAGIC as the default
> executable format?
   
   Would you please enlighten me for this one too?
   
> Wow... how can you hate modern BSD and yet know so little about it (or
                          ^^^^^^^^^^
> maybe I've just answered my own question).
   
   I find certain problems with this term. First be sure to remember that
BSD stands for Berkeley Software Distribution. An OS that doesn't come from
UC Berkeley (like the one that most of this group is hung up on) is not
BSD. The fact that it has these three letters in its name is immaterial
(it's unfortunate that CSRG hasn't made it a trademark). This definition is
very restrictive. It excludes OSes like SunOS and Ultrix (and my project,
for that matter) from BSD. To deal with this, I sometimes use a generalized
definition that includes any OS that fully retains the Berkeley spirit.
   
   Note that I usually use the term Berkeley UNIX(R), rather than BSD, to
refer to my favorite OS. There is a reason for this. The name BSD
emphasizes distribution, while the term Berkeley UNIX(R) emphasizes
ideology. I use the name UNIX with the registered trademark symbol to
indicate that an OS is faithful to the ideology of the holy original AT&T
UNIX(R) V6 and V7. This includes all CSRG releases up to 4.3BSD-Tahoe,
Ultrix, and to a large extent SunOS. 4.4BSD deviates from this ideology
significantly in some areas, and its derivatives like FreeBSD and NetBSD
follow it. That's why I have mixed feelings about viewing "modern BSD" as
Berkeley UNIX (or as BSD, since Berkeley Software Distribution is really a
synonym for Berkeley UNIX(R)).
   
> mmap() maps files or devices into memory. See "man mmap" on 4.4BSD,
> NetBSD, SunOS, Solaris, or just about any recent UNIX.
>
> mmap() is the foundation of SunOS-style (which is the NetBSD style)
> shared libraries. It's also incredibly useful for all sorts of things.
> I'd go so far as to say it's the most important system call added to
> UNIX since the introduction of networking, and it's had a radical effect
> on the way people write UNIX software. So, I'm sure you'll hate it.
   
   Let's look at this from a purely objective perspective. My first and
foremost argument in favor of 4.3BSD is its exceptional VAX support. This
support has been broken in Net/2 by the exact same new VM that makes
mmap(2) possible. I'm sure that there are a lot of other changes in the
kernel interfaces in 4.4BSD. I'm sure that a lot of these changes are
necessary for an OS to be "modern BSD". And I'm just as sure that the VAX
portion of the BSD source tree has not kept up with any of these changes.
(For what it's worth, the same applies to the Tahoe portion.) Bringing the
VAX code up-to-date with the kernel changes in "modern BSD" would probably
be anything but easy. It is likely that the code would have to be re-
structured by starting with a fresh base and porting the 4.3BSD code piece-
by-piece. The result would be NetBSD/vax with all its problems (lack of
satisfactory support for anything except MicroVAX II and MicroVAX 3). Each
piece ported from 4.3BSD would have to be tested and fine-tuned all over.
4.3BSD-Tahoe supports 8600, 8200, 780, 750, and 730. I for one don't have
any of these machines, and I certainly can't do this porting and expect the
result to work. Most other people on this list are also limited hardware-
wise. It seems to me that one of the major reasons why the support for
KA42/41 has more problems than that for KA410 and KA43 is that Bertram
doesn't have a KA42 or a KA41. Unfortunately ARPA doesn't fund BSD
development any more.
   
   Also consider the fact that 4.3BSD is very coherent and homogeneous.
There is very little non-Berkeley code in it, and when its developers were
testing it, they had a very good feeling for what they were testing. As a
result, all pieces of 4.3BSD have been tested TOGETHER really well. 4.4BSD
loses this quality. It incorporates a lot of outside code, and CSRG has
been disbanded before this code was fully polished up and coordinated with
the rest of the system. As a result, 4.4BSD is not as stable and well-
tested as traditional Berkeley UNIX(R) releases. I have a feeling that
4.4BSD's follow-ups like FreeBSD and NetBSD haven't eliminated this
problem. Being developed by volunteers without ARPA's support, they simply
don't have enough resources for proper polishing and testing. Just imagine
how much did it cost CSRG to keep at least one machine of each supported
VAX model all the time to test each release on all supported machines.
   
   This coherent nature of 4.3BSD is exactly the reason why I have decided
to take 4.3BSD as it is and do only the absolutely necessary changes,
rather than launch a large-scale pick-and-choose campaign spawning all
versions from the original 4.3BSD to the latest NetBSD as I was planning
originally. The "absolutely necessary changes" are:
   
   - Take NFS from HPBSD 1.x. NFS is absolutely essential for UNIX
"clusters". HPBSD 1.x is 4.3BSD vintage, so this should not introduce any
impurity problems.
   
   - Take the userland networking and security programs from 4.3BSD-Reno or
4.4BSD. Kerberos is almost as essential for UNIX "clusters" as NFS, and it
also greatly improves security. 4.3BSD's single publicly-readable password
file is a large security hole. This change also should be relatively
painless, since the networking and security code really stands out from the
rest of the system and has nothing to do with POSIXisation or other thorny
areas. It is also all-Berkeley in all versions, so there are no ideological
problems.
   
   - Add BabyVAX support. I will write all the code myself, but I will take
IDEAS (as opposed to code) from Ultrix and NetBSD. This is almost why I'm
undertaking this project in the first place. This change shouldn't cause
any problems either, since I won't displace any of the classical VAX-11
support code. In fact, I will draw on it extensively.
   
   Another consideration in favor of 4.3BSD is its very compact size
compared to 4.4BSD and NetBSD/vax. Believe me, this difference (by a factor
of 3!) often does make the difference between possible and impossible
(having a single RZ23 in mind here).
   
   Fortunately, the flame war that I have inadvertently started seems to be
cooling down, and having it heat up again is the least thing I want. I am
writing this posting only to share my thoughts with you, NOT to waste
bandwidth on pointless "I'm right, you are wrong" arguments. Please don't
respond to this posting with yet another flame, there are plenty of them in
the archives. If you want to be helpful to the BabyVAX user community, help
me find copies of 4.3BSD-Tahoe and 4.3BSD-Reno tapes, and let the people
look at my work on BabyVAX support and decide for themselves.
   
   Sincerely,
   Michael Sokolov
   Phone: 440-449-0299
   ARPA Internet SMTP mail: sokolov@alpha.ces.cwru.edu