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.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Server Hardening
- EnterpriseDB's EDB Postgres Advanced Server and EDB Postgres Enterprise Manager
- The Death of RoboVM
- BitTorrent Inc.'s Sync
- The Humble Hacker?
- The US Government and Open-Source Software
- Open-Source Project Secretly Funded by CIA
- ACI Worldwide's UP Retail Payments
- New Container Image Standard Promises More Portable Apps
- AdaCore's SPARK Pro
In modern computer systems, privacy and security are mandatory. However, connections from the outside over public networks automatically imply risks. One easily available solution to avoid eavesdroppers’ attempts is SSH. But, its wide adoption during the past 21 years has made it a target for attackers, so hardening your system properly is a must.
Additionally, in highly regulated markets, you must comply with specific operational requirements, proving that you conform to standards and even that you have included new mandatory authentication methods, such as two-factor authentication. In this ebook, I discuss SSH and how to configure and manage it to guarantee that your network is safe, your data is secure and that you comply with relevant regulations.Get the Guide