Errata

The very first code example "hello world" does not compile on my 2.4.19 Linux system
following the sample instructions in the book. If you do a Google search you will
see many others running into the same problem, often commenting that they got the
code from this book.

http://www.google.com/search?q=parse+error+before+atomic_t

I have not yet figured out what the problem is. I cut-n-pasted the code directly
from the book and typed in the simple "gcc -c hello.c" exactly as shown and this is
the result. I'll submit another errata if I find a solution.

gcc -c hello.c
In file included from hello.c:4:
/usr/include/linux/module.h:60: parse error before `atomic_t'
/usr/include/linux/module.h:60: warning: no semicolon at end of struct or union
/usr/include/linux/module.h:60: warning: no semicolon at end of struct or union
/usr/include/linux/module.h:62: parse error before `}'
/usr/include/linux/module.h:62: warning: data definition has no type or storage
class
/usr/include/linux/module.h:91: parse error before `}'
make: *** [hello] Error 1

First my solution:

compile with:

gcc -c -I /usr/src/linux-2.4.18-3/include/ hello.c

When the directory is not included my gcc uses files from /usr/include/
that don't work.

I am running redhat 7.3 that has not been updated. It has kernel 2.4.18-3.
The wrong module.h does not include <asm/atomic.h> so hello.c and hello1.c
and hello2.c from the misc samples fail to compile.

Adding <asm/atomic.h> gets them to compile but they don't load apparently
because the wrong version.h sets the version to 2.4.9-9.

I had recompiled my kernel a number of times and tried to produce a non-
versioned kernel. It failed after booting because it couldn't load fs
modules because it was apparently trying to load the original version.
I couldn't find anything at www.linux.it/kerneldocs/kconf.

I compiled a new kernel with versioning thus ending up with a working
kernel and matching header files. hello.c works fine just as printed
in the Book. (without any extra versioning stuff)

The problem i found it's not an error in my opinion, but something that is missing to
implement the examples correctly.

To use the example:
printk("The process is "%s" (pid %i)
" ,
current->comm , current->pid);

I had to include the header file <asm/segment.h> and <asm/uaccess.h> to the example
work.

Without it, the module would generate a Oops error.
The kernel which i am using is the 2.2.16 (Slackware 7.1).

"Nowadays, more than 256 minor numbers are needed at times,"

Should it here be not "minor", but "major"?

/* ldd2-samples-1.0.1/scull/main.c, lines 765-777 */

for(i=0; i < scull_nr_devs; i++ ) {
scull_devices[i].quantum = scull_quantum;
scull_devices[i].qset = scull_qset;
sema_init( &scull_devices[i].sem, 1 );
#ifdef CONFIG_DEVFS_FS
sprintf( devname, "%i", i );
devfs_register( scull_devfs_dir, devname,
DEVFS_FL_AUTO_DEVNUM,
0, 0, S_IFCHR | S_IRUGO | S_IWUGO,
&scull_fops, // <<<**** should this be scull_fop_array[i] ?
scull_devices+i);
#endif
}
QUESTION :

Should the '&scull_fops' parameter above be 'scull_fop_array[i]'
instead ? This is gathered from reading the scull_open() func in
pgs 70-71 of the book where scull_open() does not reassign
filp->f_op if devfs is used (filp->private_data is valid).

the scull_write code uses memset to initialize dptr->data, then, at page 88,
6th paragraph, you use sprintf for creating devnames. Can I use standard calls
into my kernel modules?? You write at page 17, 4th patagraph "because no library
is linked to modules, source files should never include the usual headern files"

The description of the function interruptible_sleep_on_timeout
lists the return type as void. It is, in fact, long. See linux/sched.h

"otherwise the kernel may run the task queue before your task has been added."
-doesn4t make sense!

This cannot be a correct statement if what is said about The Immediate Queue is
correct here and on pages 272-273.

The AXP version of GCC has no perm.h, consequently two files in the misc-progs
subdirectory must be modified for them to compile on an Alpha-based platform.

Both inp.c and outp.c require the same modification:

Rearrange the ifdef's so that:

#ifdef __GLIBC__
...
#endif
#ifdef __i386__

becomes:

#ifdef __i386__
#ifdef __GLIBC__
...
#endif

echo -n "any string" > /dev/short0

issued at the shell prompt only creates a file 'short0' in the '/dev' catalog with
the meaningless content "any string".

The qustion remains - How doe one write to the parallel port? Should a file with the
mentioned while-loop be written? In what way?

The shared variable short_bh_count is not correctly
maintained, even with uniprocessor kernels. For example, if
short_do_tasklet has just cached the previous short_bh_count
in savecount and short_tl_interrupt runs, the corresponding
increment of short_bh_count can be lost when
short_do_tasklet resets it, even though the fact of (at
least one) interrupt occurring will be detected when the
rescheduled bottom half runs again later. I believe this
can be fixed by using a spinlock in the manner described on
page 282.

Although in this case short_bh_count isn't terribly
important, some interrupt handlers need to know *exactly*
how many times they've been invoked, so correcting the
example would help avoid subtle driver problems when people
copy it. I have not tried to see if there's some reason why
tv_head in this particular example should also be protected.

(If in fact this is *not* a problem, a footnote explaining
why it can't happen would be nice.)

spinlock_t short_bh_count_lock = SPIN_LOCK_UNLOCKED;

void short_tl_interrupt(int irq, void *dev_id, struct pt_regs *regs)
{
do_gettimeofday((struct timeval *) tv_head); /* cast to stop 'volatile' warning
*/
short_incr_tv(&tv_head);
tasklet_schedule(&short_tasklet);
/* Protect interrupt count integrity if bottom-half is active */
spin_lock(&short_bh_count_lock);
short_bh_count++; /* record that an interrupt arrived */
spin_unlock(&short_bh_count_lock);
}

/* Same for short_bh_interrupt */

void short_do_tasklet (unsigned long unused)
{
int savecount, written;
unsigned long flags;

/* Block interrupts and hold lock while we read and reset the
* interrupt counter. */
spin_lock_irqsave(&short_bh_count_lock, flags);
savecount = short_bh_count;
short_bh_count = 0; /* we have already been removed from the queue */
spin_unlock_irqrestore(&short_bh_count_lock, flags);
...

A function "atomic_add_and_test" is described. This function does not exist. Or, at
least, it is not present in <asm/atomic.h> of 2.4.18-rc1.

Also, that block of atomic functions are described as returning "the previous value
of the atomic data type". This could arguably be what they *should* return, however
what they *actually* return is: "true if the result is 0, or false for all other
cases."

Functions atomic_add_and_test() and atomic_dec_and_test() do not exist. (as of
linux-2.4.20). The description of functions atomic_inc_and_test() and
atomic_dec_and_test() is wrong. As written, it states that these functions:

"These functions behave like their counterparts listed earlier, but
they also return the previous value of the atomic data type."

This is wrong. In addition, its not immediately obvious what functions
"counterparts" refers to. Since it requires more text to point to the previous
functions, better would be to just repeat it. I recommend the quoted text above be
changed to:

"Increment or decrement an atomic variable. Return 1 if the new value is 0,
otherwise return 0."

At least with kernel versions 2.4.4 and 2.4.18, the mmap(2) manual page gives the
prototype for the mmap system call as
void * mmap (void * start, size_t length, int prot, int flags,
int fd, off_t offset)
not the
mmap (caddr_t addr, size_t length, int prot, int flags,
int fd, off_t offset)
given in the book.
The distinction (and the supporting detail in the man page, which is not provided in
the book) is essential to understanding Chapter 13.

The functions are enumerated in order kiobuf_init, alloc_kiovec,
free_kiovec, but its description are:

These functions handle the allocation, initialization,
and freeing ...

I think it is better to be in order initialization, allocation,
and freeing.

It is worth to clarify the following rule for 'skb' ownership:
- if hard_start_xmit returns 0 (success), driver is responsible for future 'skb' deallocation;
- if hard_start_xmit returns non 0 (error), core network code will deallocate 'skb'.
Driver in this case shall not deallocate 'skb'

Crash of system linux