4.3 BSD system call vs. system V system call

[Doug Gwyn]

In article <2226 at ndsuvax.UUCP> ncchoudh at ndsuvax.UUCP (Akhil Choudhury) writes:
>        Are you aware of any software that will replace all 4.3 BSD
>system call to System V system call (running on AT & T).  How much
>time do you think this project will take if one workes for 8 h/day!!
>Thanks in advance.

I think you're asking about an emulation of 4.3BSD that would run on
a native UNIX System V system.  Having developed an emulation is the
other direction a few years ago, I believe I can estimate how hard
this would be.

There are three main ways of implementing such an emulation:
	(1)  Merge the kernels, as is being done by Sun and AT&T for
	UNIX System V Release 4.
	(2)  Provide "dual" kernels and some way for user processes
	to specify which one they need to use, as was first done
	commercially in Pyramid's OSx.
	(3)  Provide a replacement C library, compiler, etc. that
	intercept 4.3BSD system calls and map them into appropriate
	combinations of System V system calls.

The disadvantage of method (1), apart from the risk of breaking the
kernel, is that there are areas in which the two variant of UNIX are
incompatible, so the merged version has to merely approximate the
original system in some areas.  Whether or not this causes trouble
for application software depends on many factors.  It's probably the
best long-term solution.

The disadvantage of method (2) is that there is no easy way to mix
the behavior of the two variants in one application.  For example,
one might want basically a System V environment but still take
advantage of some of the 4BSD terminal driver features.

The disadvantage of method (3) is that it is not possible to exactly
emulate all of one system's behavior efficiently by using another's
facilities.  For example, System V IPC facilities cannot be emulated
correctly AND efficiently using 4BSD facilities (and vice versa!).

The BRL UNIX System V emulation for 4.nBSD that I developed uses
method (3).  It has been quite useful but its limitations are
becoming more annoying as time goes on.  I generally recommend
method (1), if you can get the vendor to do it and support it.
(I don't think local site hacking of the kernel to that extent,
or along the lines of method (2), is a good idea in most cases.)

If you can wait for UNIX System V Release 4, that is probably your
best bet.  If you want to proceed along the lines of method (3), it
may be a good idea to obtain my System V emulation in order to get
some general ideas about ways this method can be implemented.  (You
need an AT&T UNIX System V Rel. 2.0 or later source license to get
my package; also, regulations make obtaining the software tedious
for foreign sites.)  My estimate of the time necessary were I to
develop such a reverse emulation is about two months.  I'm not sure
it could be done at all by the sort of people who work 8-hour days.