Using iBCS2 Under Linux
iBCS2 emulation under Linux is a relatively new feature that offers you the ability to take an application that was designed to run under a system such as SCO Unix or SVR4 and run it directly on your machine running Linux. This feature is most useful for commercial applications for which the source code is not publicly available, and therefore would be impossible to simply port to Linux. In this article, I will give you an introduction to iBCS2 and tell you how to install the emulation code on your system in order to run iBCS2 programs. There will be future articles that will explain some elements in more depth.
by Eric Youngdale
The reason that iBCS2 is of interest is that there are a lot of commercial applications available for both SCO and SVR4 which people would like to run under Linux. The vendors who write these applications are often reluctant to port their application to a new platform such as Linux until they are sure that they will sell a lot of copies, and so there is no guarantee that a Linux port would ever be done. By providing iBCS2 compatibility, we suddenly make it possible to run hundreds of commercial quality applications under Linux.
At the time of this writing the iBCS2 code for Linux is still in ALPHA status. This means that you may experience problems; some applications will not run or will do the wrong thing. It also means that you are expected to have some familiarity with patching the kernel. That being said, there are only a few areas where work is still being done, and once these are complete the whole thing will become BETA. This may have already happened by the time you read this.
The term iBCS2 simply stands for the “Intel Binary Compatibility Specification 2”, and is the name of a standards document for binary compatibility between different systems running Unix on Intel 386, 486, and “greater” CPU's. Some parts of iBCS2 overlap with POSIX, and since Linux is POSIX compliant it means that there are portions of the emulation which are trivial. Unfortunately, there are also places where Linux and iBCS2 are quite different, so iBCS2 emulation is by no means trivial.
The iBCS2 emulator is mainly designed to be used as a loadable kernel module. This means that when you boot the kernel the emulator will not be present in the kernel's address space, so any attempt to run an iBCS2 application will fail. You must run a special program to “load” the emulator into the address space of the kernel, and once you have done this you will be ready to use the emulator. If you wish, you can unload the module when you are through with it to reduce the memory usage, but most people would not bother to do this.
To install and use iBCS2 under Linux requires one of several things. If the distribution of Linux that you are using already includes iBCS2, then you are in quite a good position. If this is so, then the chances are that all you will have to do is locate and load the module, and you will then be ready to run your iBCS2 applications. At the moment, the odds are fairly poor that your distribution has the iBCS2 patches already applied, so the remainder of this article will tell you how to get the emulator built and loaded.
As a prerequisite, you should be running either a 1.0 or 1.1 series kernel. You should know that the 1.1 kernels are officially development kernels, and may not be as stable as a 1.0 kernel. There are also frequent patches to the 1.1 kernels as development proceeds, so if you are a new user you are probably better off staying with a 1.0 kernel. If you are running anything older than a 1.0 kernel, you will have no end of difficulties, so your first step should be to upgrade. If you are running a 1.1 kernel, you should probably be at the most recent patch-level to minimize difficulties in compiling and installation.
Next you should get the source code for the emulator itself. This can be obtained via anonymous ftp from tsx-11.mit.edu or one of the many mirror sites of tsx-11, and can be found in the directory pub/linux/ALPHA/ibcs2. The current version of the emulator is called ibcs-940610.tar.gz, but by the time you read this a much newer version should be available. Once you have obtained this, you need to unpack it. Most people have their kernel source tree in the directory /usr/src/linux, and the examples I am about to give assume this.
To unpack, use the commands:
cd /usr/src/linux gzip -d -c path/ibcs-940610.tar.gz | tar xvf -
where you substitute the actual path of the file obtained by anonymous ftp for the word “path”.
Now you need to see whether there are any patches which need to be applied to the rest of the kernel. Look in the directory /usr/src/linux/ibcs/Patches and see what is there. At the time this was written, there is a patch file for the 1.0 kernels, but there are no patches required for the 1.1 kernels. If you are running a 1.1 kernel, then skip down to the section on 1.1 kernels. If you have a 1.0 kernel, then you should do the following:
cd /usr/src patch -p0 < /usr/src/linux/ibcs/Patches/kernel-1.0.pat cd /usr/src/linux make config make dep
When you run “make config”, it will ask you whether you want iBCS/ELF/COFF in the kernel. The correct answer is “N” if you want to use iBCS2 as a loadable module. If you answer “Y”, the source tree will be configured so that the iBCS2 emulator will be linked directly into the kernel, but this has not been tested in a long time, and will probably not work very well.
Now you are ready to actually build the emulator.
cd /usr/src/linux make
and this will build both the kernel and the iBCS2 emulator. When it is done, you will have to install the kernel image in the proper place so that you can boot from it. If you want to boot from a floppy, then type:
and you will have a bootable floppy image. If you are booting directly from your hard disk, you will have to find the configuration files for the lilo program, and see where it expects to find the kernel image. You should copy the zImage file to this location and run lilo so that this information is properly recorded. If you are not sure of what you are doing at this step, please be careful, because you can screw up your system so that it is not bootable if you do something wrong. Once you have done this, you will need to reboot so that the patches you applied to the kernel are in effect on your system.
If you are running a 1.1 kernel, and there were no patches in the directory /usr/src/linux/ibcs/Patches that you needed to apply to your kernel, then you simply need to make sure that you are running a kernel based upon the source tree into which you have unpacked the ibcs2 sources. Then you type:
cd /usr/src/linux/ibcs make
to build the emulator. If you were already running the kernel that was built from the current /usr/src/linux source tree prior to adding the iBCS2 stuff, there is no need to reboot. Otherwise you will need to either make a bootable floppy or copy the zImage file to the proper location and use lilo to register the new kernel.
At this point you are nearly done. There should be a file called /usr/src/linux/ibcs/iBCS which is the loadable module for the kernel and it is ready to be loaded. Unless you already have the “insmod” program on your system, you will need to obtain the sources to the modutils package, and you can get this from tsx-11.mit.edu in pub/linux/sources/sbin. At the time of this writing, the package is called modutils-0.99.15, and even though it is old it still works. If there is a newer version, some of the paths may have changed, so pay close attention. You can unpack this more or less anywhere, and the following commands illustrate how to do this:
gzip -d -c modutils-0.99.15.tar.gz | tar xvf - cd modutils-0.99.15 make make install
You will need to be root to do the “make install”, because it needs to copy the executables to a system directory. Once you have done this, you run the insmod program to load the iBCS2 emulator, and the following command will do the trick:
which should load the iBCS2 emulator into kernel memory.
Before you actually try and use iBCS for the first time, you need to create a few special device files. These are used for networking applications that come from SCO systems, and they are used for access to the local X server. The commands you need to run are:
mknod /dev/socksys c 30 0 ln -s /dev/null /dev/X0R mknod /dev/spx c 30 1
Now you are truly ready to run iBCS2 applications on your Linux system; you simply run them in the normal way you would run any other program on your system.
In the limited space available to me, I have described how to get iBCS2 up and running on your system. You may find that there are problems of one kind or another, and there are text files in the iBCS2 emulator source tree which you can use to help troubleshoot the system.
There are also some elements of emulation which are missing right now. Support for some types of networking (specifically TLI) are currently missing, but people are working on this, so hopefully this will only be a temporary limitation. There is support for socket-based networking, however. Also, some applications may require shared libraries of some kind or another. This is one of the areas where work is still in progress, so your best bet is to simply see what the status is by asking on the iBCS2 channel or looking in the directory of the ftp site that you got the emulator sources from, in a file called libc_s-<date>.tar.gz, libc_s-940616.tar.gz as of this writing.
In the end you may wish to obtain a demonstration version of a package before you spend money to buy the package, and you can use this to see how well the application will actually work. Some demonstration versions are available via anonymous ftp; there is a demonstration version of WordPerfect available from ftp.wordperfect.com in ftp/unix/demos/sco/sco.z. Also, there is a list of applications that are known to work in the iBCS2 emulator source tree, and this is updated every so often.
If you wish to keep up with the latest developments in iBCS2 emulation, you can join the mailing list that the developers use for discussions, posting announcements and patches. To join, you can send a mail message to firstname.lastname@example.org, and you should include the line:
X-Mn-Admin: JOIN IBCS2
either in the header or as the first line of the message. You should get a message back to confirm that you are on the list, which you should save as this also tells you how to get off the list if you should ever need to do so.
Eric Youngdale Eric Youngdale has worked with Linux for over two years, and has been active in kernel development. He also developed the current Linux shared libraries.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide