Oracle Linux, virtualization , Enterprise and Cloud Management Cloud technology musings

  • September 27, 2010

user space applications and glibc

At a very high level in an operating system there are 2 interfaces. There is interaction between the Kernel and User Space and in User Space there is interaction between application code and system libraries.

The system libraries provide a gateway to the kernel. glibc is such a library (actually the largest one at that).

Some core system tools make calls directly into the kernel using system calls but by and large the system libraries buffer all this. There is a clearly defined system call list which allows the OS vendor to do kernel updates without affecting anything in User Space. Whether these updates are bugfixes or new features.

With our new optional kernel, we did not have to replace / do not replace any of the system libraries because we maintain full compatibility with the User Space layer on top.

As such even the most complex and demanding applications such as the Oracle database, Weblogic server or Oracle Applications are in no way impacted on compatibility. These changes are totally transparent. This is one of the reasons we were confident that we could, without compatibility issues, replace the kernel by itself. The User Space applications still see the exact same system libraries, the same ABI and run unmodified.

In almost all cases of compatibility issues on Linux over the last several years (going back since day 1) it was caused by glibc upgrades. glibc 2.1 -> 2.2 -> 2.3 etc. Products built against one version would often fail against another version and often an upgrade from ELx to ELy would break applications.

The kernel ABI (kABI) does change when making major changes. This means that kernel modules, device drivers in binary format cannot just load against a kernel that has a different kABI. They would just be recompiled/rebuild. We maintain kABI for the newly released kernel within its release timeframe, similar as what you see from other Linux vendor kernels out there.

One big advantage of being able to apply this kernel on top of an existing Oracle Linux 5 installation is that you do not have to do a fresh install and go to EL6/OL6 to get new kernel features. You get the advantages right on top of your existing environment.

As many are well aware, traditionally it was required to do a new/fresh install to upgrade from one major linux of EL to the next. Just an OS install by itself is quite painless and only takes a few minutes. The real issue is when you have a complex mission critical application installed, you will most likely have to do a complete fresh install of the software and restore the data. This is risky, complex and time consuming. You have to make sure everything is configured the same way, or if you really know exactly where all the configuration files and scripts are on your system partition, you can try to backup those files and restore them but in general customers do a fresh installation.

With the new kernel, you can make use of all our new features without having to go through all this. Simply apply the oracle-linux rpm which pulls in the few required packages and you can continue, with all the advantages. Of course your system stays in the Oracle Linux 5 timeframe but the core kernel is newer, has support for the better hardware, power management, performance and device drivers. The tihngs that really matter the most for pretty much all apps.

Of course there are many 100's if not 1000's of package changes when going from one major release to the next, but often times, these packages are not required for the actual application. It might be useful for new deployments and new requirements but generally do not help at all for existing installed and running applications. This has always been a big concern of our customers.

So, you keep the exact same system libraries, the exact same userspace, no compability issues are introduced, the most complex apps keep running totally fine and a swift simple way to upgrade to this recommended kernel, all that nicely packaged with a git tree for full easily viewable source code.

And as I mentioned in a previous blog entry, for those that do not have a support subscription, you can download the new packages from our public yum repo as well.

(update : fixed a typo)

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.