Compatibility Issues Concerning the New Version of LiS

If you have used a previous version of LiS you will need to take some steps towards compatibility with the new version.

Extracting Old LiS Kernel Patches

Previous versions of LiS installed inside the kernel source tree and included patches to the kernel in order to install LiS into the kernel. There was no provision made for removing these patches from the kernel.

Beginning with LiS-1.25 any patches made to kernels whose version number is 2.0.35 or later can be removed from the kernel just by doing a "make realclean" in the LiS installation directory. If you have installed the older version of LiS in your kernel then you need to take steps to remove it prior to installing this version of LiS.

There are two methods of doing this. Both are manual procedures.

  1. Change the name of your kernel source directory, as in
  2.       mv /usr/src/linux /usr/src/linux.old

    and then untar a fresh kernel source as /usr/src/linux. This method works fine if LiS was the only patch to your kernel. Once the new kernel works, remove the linux.old directory.

  3. In your kernel tree, do the following:
     cd /usr/src/linux/drivers
     rm -r streams

That deletes almost all of the files that came with the old version of LiS.

Next, you must restore the patched kernel files to their original state. From the directory /usr/src/linux, look for the following files:

LiS:

Semaphores:

If you do not have any other patches applied to these files, then change their names back to the original file names (these names minus the .orig suffix). Not all of these files will be present on every version of the kernel. Kernels later than 2.0.30 would not have had the semaphore patch, for example.

If you have other patches in these files then you will need to consult one of the following files from the newly installed /usr/src/LiS directory:

There is really no recourse at this point other than to examine the patches and manually extract the LiS patches from the affected files.

Open Flags

The open flags MODOPEN and CLONEOPEN have been changed since the previous version. You must recompile your STREAMS drivers using the new header files in order to incorporate this change. The change brings the bit assignments into conformance with SVR4.

STREAMS drivers compiled against the old header files should not be linked into LiS without recompiling. The old open routines will misinterpret their flags argument.

System Calls

This change affects all application level programs that use the STREAMS constructs getpmsg, putpmsg or poll.

For kernel versions prior to 2.0.36, LiS did not have official system call numbers assigned for getpmsg, putpmsg and poll. Beginning with kernel version 2.0.36, and all 2.2 kernels, LiS has official system call numbers assigned for getpmsg and putpmsg. The 2.2 kernels have a built-in poll system call. Therefore, there is no LiS poll system call in 2.2 kernels.

The system call slots that LiS used for getpmsg and putpmsg in earlier kernels were, of course, taken up by other functions by the time the official system call slots got assigned for the 2.2 (and 2.1) kernel. That means that older STREAMS applications compiled for use with earlier versions of LiS, when run on newer kernels, will be issuing incorrect system calls for getpmsg and putpmsg. These applications need to be recompiled and relinked using the new LiS.

The new version of LiS, even when run on kernels prior to 2.0.36, will always plug the system call table slots for the new "official" STREAMS system calls in addition to the older ad hoc slots. This means that you can use applications that utilize putpmsg and getpmsg with the new system calls on older kernels by using the new version of LiS.

However, the poll system call is not so easy. If your application uses poll then you must maintain a version of it that is compatible with kernel versions prior to 2.0.36 and another version that is compatible with kernel versions 2.0.36 and beyond, including 2.2 kernels. The reason for this is that prior to 2.0.36, LiS contained the only implementation of the poll system call. However, starting with 2.0.36, the kernel contains its own implementation of poll and the LiS implementation must yield to the kernel's implementation. The system call slot used by LiS for poll and the one used by the Linux kernel are different. So there is really no way around maintaining two versions of such applications.

The following table summarizes the system call number assignments for different kernel versions. Numbers in plain text are the ad hoc numbers used by earlier versions of LiS. Numbers in italics are official kernel assigned numbers. The problem with the poll system call is that the number 169, used by earlier version of LiS, is used for a different system call in kernel version 2.0.36 and beyond. Thus, it is not possible for LiS to plug that system call slot with a pointer to its poll routine for backward compatibility.

Version

Getpmsg

Putpmsg

Poll

LiS for kernel versions < 2.0.36

168

167

169

LiS for kernel version 2.0.36

188

189

168

LiS for kernel versions >= 2.2.0

188

189

168

In kernel versions 2.0.36 and earlier, LiS provides the implementation of the poll system call. In 2.2 kernels, the kernel provides the implementation of poll and LiS hooks into it on behalf of its STREAMS drivers.

Libraries

The older version of LiS had direct inline code for STREAMS system calls defined in stropts.h. The new version contains function prototypes in stropts.h with the actual system call code contained in a library that you link with your application program.

The library resides in the directory /usr/lib and is named libLiS.a. Thus, you need to include the directive "-lLiS" with the link of your STREAMS applications.

Interactions with Other Packages

On kernel version prior to 2.0.36 there can be problems with LiS interacting with other packages such as JDK and, perhaps, iBSC. In particular, JDK looks to see if system call number 168 has been assigned. If it has, it assumes that the operating system implements the poll system call in that slot. As you can see from the chart above, older versions of LiS did plug system call 168, but with the getpmsg routine, not with poll. Although we do not know for sure there is a possibility that iBSC would have the same problem.

The solution is to upgrade to a kernel at least as new as 2.0.36 or a 2.2 series kernel.