[UKUUG Logo] Copyright © 1995-2004 UKUUG Ltd



Newsletter Section 2


Linux Kernel Internals

M Beck, H Bohme et al
Addison-Wesley Longman
ISBN 0-201-87741-4
(Reviewed by Jon Lacey)

There have been plenty of “Installation and getting started” and “Using” Linux books around for the last year or so, but at last something for the more technical bods to get their teeth into. This book attempts to give an insight into what a Linux kernel is and what makes it work.

This is definitely not a beginners' text, it is aimed at people who have a good knowledge of C, who know quite a bit about UNIX basics and now want to be able to understand the internals of a kernel and how to program it. Up until now the only way of finding out how to change something in the kernel was to wade through page upon page of very sketchy documentation, or attempt to find the necessary information among the thousands of lines of C code that make up the kernel. Although wading through the source code is a good way of learning, it is nice to have a text book that helps us on our way, and this is that text book.

As the Linux kernel is an ever developing entity, you have to start somewhere, so this

book concentrates on the 1.2 kernel which is the one that the majority of people still use.

The book starts with an overview, where to find everything on a Linux system and how to compile a kernel. It then goes on to describe the data structures and algorithms used and how to implement system calls. Memory management gets good coverage and details the architecture-independent memory model and how block device caching and paging is undertaken.

Another chapter explains the basic principles and the representation of the Linux file system. The proc filesystem, in its way peculiar to Linux, but in general resembling the process file system of System V R4, provides information on the current status of the Linux kernel and its running processes. This section describes how the proc filesystem is implemented and is followed by a description of the Ext2 filesystem which is used in most Linux systems and distributions.

Chapter seven, on device drivers, explains the differences between character and block-oriented devices, polling and interrupts, and how Direct Memory Access is used to continuously transport large volumes of data. The chapter finishes with an implementation of a device driver for the internal loudspeaker and goes through the process of examining and detecting the hardware and then implementing a driver to access it.

The appendices cover some 100+ pages of system calls, kernel-related commands and the boot process. The system calls are listed giving their call, the needed include files,

and how they are implemented with code showing the details.

The section on the boot process explains how booting is carried out and describes the option available to LILO, the LInux LOader. The book finishes with a reference that not only gives the details of the various available texts, but a brief description of what they cover.

This book is written by six people who share their expertise with us in writing about what they know best, and leaving other sections to the experts in that field. There is a seamless integration of the various styles of writing and knowledge into a well-presented volume that includes a lot of information that has been previously notoriously difficult to find.

Running Linux Companion CDROM

RedHat Linux Release 3.0.3
O'Reilly & Associates and RedHat Software
ISBN 1-56592-212-3

(Reviewed by Jon Lacey)

Tales of Woe: Part 1

First of all the background. I have used Linux (Slackware) for about two years now; before that I was a committed DOS user (sad, I know) for the years previous. My experience with Linux has been varied and, although I could not call myself a Guru by any means, I have done the usual: setting up filesystems, adding new disks, compiling kernels and the like. I thought that I was quite prepared for a “simple” installation of a different flavour (RedHat).

I had previously bought a secondhand SCSI drive and interface card and I thought this would be the easiest way to install. I could leave my Slackware setup untouched and install RedHat on the SCSI drive. I ensured the SCSI kit was alright by checking that it worked with Slackware. This did entail a slight kludge; editing a header file, re-compiling the kernel and passing an option to LILO to call the interface card a Seagate, instead of a Future Domain, but I thought that the newer version of RedHat would have had all this done for me - how wrong I was to expect such a thing.

Here goes. I mounted the CD (disk 1) under Slackware and made boot and root floppies with the SCSI image file; this was all completed with a nice Perl script ( mkfloppies.pl ). Everything seemed to go alright here and I ended up with a boot disk, two root disks and a rescue disk (now I know what the rescue disk was for!).

I re-booted the system with the boot disk in the floppy drive and the CD (disk 1) in my CDROM drive. Whirr, whirr, clunk, buzz and up comes the Lilo prompt informing me to add anything I needed to the boot prompt, if my hardware was not being recognised. I added a line to recognise my SoundBlaster card, as I know that they have problems, and up the system came, after changing the boot for each of the root disks in turn.

After a few questions it was obvious that my SCSI apparatus was not being recognised, so I re-booted and added the line to LILO telling what and where my SCSI card was. Another reboot but still nothing. I tried different options and after removing my SCSI card and changing jumpers, gawd knows how many times, I thought I had better enquire of the experts how best to continue.

An e-mail to RedHat told me I was not covered for any support and it was best to contact O'Reilly. This I dutifully did and was informed by a gent at O'Reilly that he wold contact RedHat and get back to me. While I waited, I continued to try, but alas no luck. The reply came from O'Reilly (quickly, it must be said) that nobody could help with this one and could I not “try another drive”. I was not too impressed with this as I had almost purchased the SCSI kit for the sole purpose of trying out different flavours of Linux.

Anyway, I thought I had best try something, so I went about tar ing , gzip ing and generally messing my Slackware system up, just to try to load RedHat.

I ended up with two partitions on an IDE drive /dev/hdc that has never given me any problems under Slackware, but guess what? After going through the steps above, I get to the stage where RedHat asks what drive I want to install on. I tell it and it says ok; do I want to format that partition, yes ok; what software do I want to install, I tell it what I want and away it goes. I think MAGIC I have done it. The next step asks me if I want to use LILO to boot the system, I say yes and that I would like to have LILO installed on a boot floppy (I have messed up the Master Boot Record before and wasn't going to give RedHat the pleasure). The options were given to LILO and the machines starts to seek the floppy to write the boot sequence to. WHAT! I am told that because my partition doesn't start on a physical boundary, it can't carry out the operation. I am flabbergasted (my flabber has never been so gasted - to coin a phrase). This has never been a problem with Slackware, I am near to tears.

I reboot Slackware to check some things out and find I have trashed my setup (I know, serves you right, where's your backup, you saved your setup files didn't you?).

After getting my Slackware system up and running again, I need it for daily use, I think what to do next? I have an old IDE drive in an ancient 386 that I remove and install in my system, it's only 116MB but that is enough to get the basic RedHat system working, so off I go again.

I set the drive up in the BIOS, check it under Slackware, re-partition it, format it and generally check everything is ok, before I attempt RedHat again. Everything looks ok, so I think I will give it one last go - I have the twiggy branch ready to give it a good thrashing, just like John Cleese in Fawlty Towers (I hope you remember that), and away we go yet again.

I am getting pretty well acquainted with the install script by now and I speed through with consummate ease. I get to the LILO prompt and, fingers crossed, it writes to the floppy and all looks to be ok. I have a quick break and swig a brew or five and congratulate myself on a job well done.

Ok, here goes. I fire up the computer with the newly formatted and LILO'd floppy in the drive click, click, whirr, whirr, gets to the LILO prompt, sorry I should say LI ( Linux aficionados know what I mean) prompt and it all goes pear-shaped again. The system just sits there with the LI prompt and I think I can hear it chuckling at me.

A quick look through the LILO documentation tells me, that LI probably means that the first stage loader has been able to load the second stage loader, but not able to execute it and this is usually caused by a geometry mismatch. I can only presume it doesn't like this hard disk either. Well, that's it, I have no hair left, I am an alcoholic and I am nearing divorce.

I give up - I need a holiday!

Tales of Woe: Part 2

Well it has got better since the last time I wrote. I have messed around with my BIOS and reset the cylinders, heads and sectors of the drive and I now have it recognised. Here goes again.

I go through the install again and install as much as I can with the available space. This time I thought I would go for an X installation (it's supposed to be easier to install with graphics), but my graphics card is not supported under this version of X, so back to the text-based installation.

This time everything goes OK and everything seems to load OK. I am asked about using LILO for booting and I say yes to the “install on floppy” parameter and hold my breath.

It looks as though the image has been written to the floppy. I still get warnings about the disk geometry, but as the message flashes past so quickly I cannot see what it says.

Anyway, I reboot and the floppy starts LILO, I insert the line to tell it about my Soundblaster and CD drive and up it boots. So here I am two weeks later with a Linux system running at last.

I look through the accompanying book for some help with installing more packages and setting up the system, but 90% of the documentation points to the control-panel to set things up. Control-panel is X based so I cannot use it. I do think there could be something written for a text-based setup. It is not an easy task for a newbie to set up printing and the like, but at least it's working.

My final thoughts on this are:

It is a good job I have some *NIX knowledge or I would have been left with a couple of coffee mats and another book for the bookshelf. There is a lot of talk in the Linux circles that the installed base is

growing rapidly. If we could avoid experiences like this I am sure there would be many more converts.

I know that I may be an isolated case, but I do not think that my hardware is obscure and I think it should be possible to have a flawless install for it.

Ah well, back to Slackware.

Jon Lacey is an Open University student who in his spare time (not much of that, let me tell you) is trying to teach himself how to use the *NIX operating system so he can get a decent job in the big bad world of computing.

SUN UK User Group Linux Technical Meeting

19 June 1996
Manchester Conference Centre.

(Martin Houston)

The reason behind the Sun User group organising a free whole day seminar on Linux was to spread the word about the Linux port to the Sun Sparc. As you shall hear later, there was plenty of positive news about that, but the day was also of value to anybody interested in Linux and where it is heading.

Over eighty people attended the conference drawn from the Sun UK User Group, UKUUG Linux SIG and the local Manchester Linux User Group. This makes it the best attended Linux event in the UK yet (I know, readers in the US and Europe are probably laughing).

The programme kicked off with a talk by Olaf Kirch, author of Linux Network Administrators Guide, on the evolution of Linux and where it is going. Linux has been under development for about five years now, the pace has been rapid, the present is a standard stable system in the form of Linux 2.0 with improved speed, networking and hardware support. The future is a greater involvement of commercial interest in Linux, even more speed and support for new hardware types.

Next on the agenda was David Miller, who had been flown in from Rutgers University, who entertained us and informed us of his attempts to port Linux to the Sun Sparc. A great moral is: if you want something done just tell a hacker that it can't be done! Without any privileged knowledge about Sun's own UNIX versions, David and his

team have managed to adapt Linux to suit several different generations of systems in the SPARC family tree. The new ways of doing things that Linux brings with it, together with a dedication to performance testing and tuning, means that Linux for SPARC consistently out-performs the machine's original operating system! A particularly useful part of the testing armoury described was a program called crashme , whose function was to fill a memory area full of random bytes and then get the system to try to execute them!

On a well-behaved OS, a rogue program such as this should be terminated sooner or later, but not bring the system down with it. The SPARC port of Linux at least can survive repeated crashme attack for days!

After the technical details of the Sparc port, the next talk was a presentation on actually using Linux in a university environment by Andrew Cormack and Chris Cook of the University of Wales, Cardiff.

Chris Cook spoke first of his experiences with Linux. It was the most effective way for him to telework. Chris is a technical support person for the University network, but wanted to be able to work from home to be on hand to help out after his daughter was born. A 486 machine running Linux, connected to the University through a dial up SLIP link, proved the ideal solution. Being able to use netware administration software from within the Linux DOS emulator, on a remotely connected machine, even gave him the ability to administer the Novell network from home, as well as any other UNIX resources.

Andrew Cormack then took over and explained how Linux departmental servers were being used within the University itself for mail and web services. The fail-safe nature of many internet protocols means that a system can be devised, so that the failure of the departmental level systems is inconvenient but not serious. In the event of such a failure, services fall back to the central, supported, system. In practice the Linux systems give little trouble and take lots of load of the central systems and network backbone.

After lunch, David Miller was back on the podium, this time with some heavy technical details of how the Sparc specific parts of the Linux kernel were designed - including a clever scheme of boot time patching, to allow the various memory management schemes used by different models to be accomodated with no loss in performance.

Following David Miller was our own Alan Cox with a discussion of the state of Linux networking.

The mainstay of networking is of course TCP/IP support. Linux TCP/IP networking is now so optimised in the 2.0 kernel that a 486 can saturate a 100MB/s ethernet. Alan has to look at faster technologies like HIPPI and IP over fast wide SCSI to give something fast enough to aim further code optimisation at!

Linux is also very strong at supporting other network protocols such as Appletalk, simple Novell client and server and even Windows for Workgroups/Windows95.

After tea the day was rounded off by a lively question and answer session to the whole panel of speakers. Among other things we learned that the US Department of Defense is funding work on improving Pentium code optimisation in the gcc compiler - work which will in time come to benefit the Linux community. Another question was “What were the current extremes of machine power that Linux runs on?” At the low end Linux is useable on a 16MHz 386sx with 4MB of memory (about 2.5 BogoMips) and, at the high end, the DEC Alpha has the current highest single CPU rating of 400 BM. Alan Cox has a 4 CPU Pentium pro that manages about 790 BM. There is, however, work going on with massively parallel Linux machines that have much higher ratings than that!

In all the day was highly informative and enjoyable. More events like this are needed and on a larger scale.

I almost forgot to mention: delegates also queued to purchase a wide range of O'Reilly books at 25% discount, thanks to Julie Carroll Davis, from International Thompson Publishing, who had set up a stall. The word is that Linux books are selling very well at present and more titles are on their way - so look out for reviews in Linux World and new books appearing at your local bookstore.

Many thanks to Daf Tregear of the Sun UK User Group for organising such an enjoyable event and Dr Owen LeBlanc of the Manchester Linux Users Group for chairing the panel discussion.

Tel: 01763 273 475
Fax: 01763 273 255
Web: Webmaster
Queries: Ask Here
Join UKUUG Today!

UKUUG Secretariat