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.
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.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Huge Package Overhaul for Debian and Ubuntu
- Home Automation with Raspberry Pi
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development