COMPAT_43 and the linuxolator

David P. Reese Jr. daver at
Fri Aug 15 19:22:11 PDT 2003

In article <200308160150.h7G1oqcQ083933 at xxxxxxxxxxxxxxxxxxxx>, Matthew Dillon wrote:
>     We definitely can't rename COMPAT_43 to COMPAT_LINUX for the
>     remaining functions.  Could you post an example of the problem
>     area?  It seems it ought to be possible to convert the linux code
>     to use the newer syscalls.
> 					-Matt

For example take a look at sys/kern/uipc_syscalls.c:accept1().  accept()
and oaccept() are wrapper functions which pass differing flags to
accept1() to turn on and off the logacy code.  Here is a snip of the
legacy code in accept1().

        if (uap->name) {
                /* check sa_len before it is destroyed */
                if (namelen > sa->sa_len)
                        namelen = sa->sa_len;
                if (compat)
                        ((struct osockaddr *)sa)->sa_family =
                error = copyout(sa, (caddr_t)uap->name, (u_int)namelen);
                if (!error)
                        error = copyout((caddr_t)&namelen,
                            (caddr_t)uap->anamelen, sizeof (*uap->anamelen));

The COMPAT_43 option turns on COMPAT_OLDSOCK which trashes the sa_len field
of the sockaddr struct to be compatible with 4.3BSD.  This occurs just
before the copyout.  This seems to be the main problem with the linux
emulation code.  It relies on alot of the old syscalls which use the old
sockaddr struct.

The trouble is that both the casting to a osockaddr struct and the copyout
happen in the syscall functions.  Thus it sounds like we need to implement
the legacy syscalls in the linux emulation code.

With the messaging system in place we will be able to intercept messages
in the emulation layer and modify their contents before passing them on,
right?  This would solve the problems that I'm having with changing
structures before a copyout.

On another note:
I think it would be a better idea to remove COMPAT_43 instead of fixing
it because the legacy compat code is scattered all over the place.

   David P. Reese, Jr.                                     daver at xxxxxxxxxxxx

More information about the Kernel mailing list