Programming Tips...

 in
In this initial column, I'll explore porting programs from other Un*x versions to Linux. Porting Un*x applications to Linux is best done, as a general rule, by porting the application to some standard which Linux follows. This way, not only will Linux users benefit from your port, but so will users of other operating systems which follow the same standards. As always, there are some exceptions.
System Dependencies

Some code simply requires functionality that isn't defined by any standard, or at least any sufficiently popular one, and is therefore written separately for each operating system. An example of this is finding the current load average or other indication of system load. For most implementations of Un*x, this requires that a process have superuser powers, and that it go looking in special places in kernel memory for magic numbers. Exactly where to look in the kernel memory (usually /dev/kmem) is determined by the derivation of the source code—SYSV code looks in one place, and BSD code looks in another. On other operating systems, many various methods are used.

In Linux, the load average can be obtained by any process by simply reading the file /proc/loadavg--you can see it yourself at the command line by typing cat /proc/loadavg. Fortunately, this and many other special features like it are standard across all installations of Linux and fairly easy to use.

Unfortunately, there are a few problems you may run into that are not quite as tractable. The formats of some files, such as /etc/utmp, are not all well-defined under Linux. That is to say, standards do exist, but they appear to be interpreted differently on different platforms. This situation will hopefully improve over time, but right now, it appears to be difficult to write code which works on all Linux installations.

For now, I recommend having a reasonably standard Linux distribution yourself, and making your software work on your own computer, and then ask that users who have problems using your software contact you. Work it out for each individual case when they do, perhaps using #ifdef's, so that when you release a new copy of your software, it will work on more Linux installations. It will also allow your software to work on more non-Linux platforms. I also suggest getting the Linux Documentation Project man pages, which include man pages defining these formats if they did not come with your Linux distribution. Follow them in the best way you can, pointing out to the authors where and why they are not clear, and help re-write them if necessary to clarify them. With your help, these small problems can be resolved, in time.

Non-Broken Behavior

In some cases, source code written on other operating systems makes assumptions that are true on the original operating system, but which are not true under Linux because some functionality has been fixed. An example is select(). When select() was first introduced, it was pointed out in the man page that the time parameter, which was passed to select by reference (& time), was not currently modified, but that in the future it might be modified to return the time remaining in the select. Programmers either never noticed or completely ignored this advice, and now that several operating systems, including Linux, do modify the time parameter, programs which depended on it not being modified are breaking.

As a result, at regular intervals (about once a month, I think), someone posts to the newsgroup comp.os.linux.misc, saying: “The Linux select() call is broken!” even though the Linux manual pages and the Linux GCC FAQ carefully explain the situation. Operating systems keep being improved, but one thing never changes: some people will alway refuse to read the documentation.....

Some code blindly assumes that signals like SIGBUS and SIGEMT are defined, even though there is no guarantee (under POSIX) that these signals will exist on a platform. This type of code is easily fixed—simply wrap code referring to the offending signal in #ifdef SIGNAME, so that it is only included on operating systems that define that signal. Alternately, you can re-define the signals to SIGUNUSED, by adding -DSIGFOO=SIGUNUSED to the CFLAGS line in the Makefile.

Many programmers have ignored warnings not to make any assumptions about the FILE structure, and have dereferenced members of the FILE structure at will. Ignoring for the moment the argument that the original standard I/O should have included macros or functions to access those members, this causes problems under Linux, because standard I/O under Linux is based on C++ iostream library, and therefore has completely different structure members. As an example, while porting GNU Emacs 19.xx to Linux, I found that emacs wants to know how many characters are left in the stdio buffering, and the default behavior was to look at (FILE)->_ptr - (FILE)-<_base, which don't exist under Linux. Fortunately, this was done with a macro which is defined in the Emacs source, called PENDING\_OUTPUT\_COUNT, which I was able to define in the Linux-specific file linux.h as (FILE)->\_pptr - (FILE)->\_pbase.

Also, it appears that the standard libraries of many operating systems define a symbol called sys_siglist, but do not declare it. Since it is declared in the Linux header files, you simply need to comment out any extra declaration of sys_siglist in the source for the program. This is true of several other features as well: sys_siglistis only an example.

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState