[comp.unix.questions] 4.3 BSD system call vs. system V system call

ncchoudh@ndsuvax.UUCP (Akhil Choudhury) (03/01/89)

Hi,
        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.
                                                choudhury

ekrell@hector.UUCP (Eduardo Krell) (03/03/89)

If what you want is a library which would emulate ALL the 4.3 BSD
system calls on a vanilla System V machine, you're out of luck.
There are a lot of system calls which can't be emulated in user
space: you need kernel hacking.
    
Eduardo Krell                   AT&T Bell Laboratories, Murray Hill, NJ

UUCP: {att,decvax,ucbvax}!ulysses!ekrell  Internet: ekrell@ulysses.att.com

guy@auspex.UUCP (Guy Harris) (03/03/89)

>        Are you aware of any software that will replace all 4.3 BSD
>system call to System V system call (running on AT & T).

I'm not aware of any such software, which is not surprising since some
of the 4.3BSD calls are, well, irreplacable; there is no replacement for
"ftruncate", for example.

>How much time do you think this project will take if one workes for 8 h/day!!

About as much time as it'll take for System V Release 4.0 to be released
:-).  (For example, S5R4.0 should have an "ftruncate" equivalent, and if
it isn't "ftruncate" there'll probably be an "ftruncate" library routine
that uses it.)

gwyn@smoke.BRL.MIL (Doug Gwyn ) (03/03/89)

In article <2226@ndsuvax.UUCP> ncchoudh@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.