Initial commit

9781565922921

 No newline at end of file

While most  of the source  code printed in  the  book is part  of real

program files, a few of  the examples are  standalone excerpts I wrote

out of  my mind. Unfortunately, I  managed to fit  a pair of errors in

these code lines.

Page XXX

========

In chapter  9 ("Interrupt Handling"),  in the section called "Going to

Sleep Without Races", the code shown has a subtle bug.

The correct implementation of the trick looks like the following:

	add_wait_queue(&short_queue, &wait);

        do {

            current->state = TASK_INTERRUPTIBLE;

            schedule();

        }

        while ((short_head == short_tail)

		&& !(current->signal & ~current->blocked) );

        remove_wait_queue(&short_queue, &wait);

        if (current->signal & ~current->blocked) /* a signal arrived */

            return -ERESTARTSYS;

This is different from the version shown in the printed text as signal

decoding must be performed *after* calling remove_wait_queue().

Page YYY

========

In chapter 17, in the  section called "Using  the New Interface",  the

ioctl() implementation  shown includes a  stupid  mistake: "retval" is

not initilized. A correct implementation is:

	int another_ioctl(struct inode *inode, struct file *filp,

	              unsigned int cmd, unsigned long arg);

	{

	int retval = -EINVAL, size = _IOC_SIZE(cmd);

	if (_IOC_DIR(cmd) & _IOC_READ) {

	    if (!access_ok(VERIFY_WRITE, (void *)arg, size))

		retturn -EFAULT;

	    }

	else if (_IOC_DIR(cmd) & _IOC_WRITE) {

	    if (!access_ok(VERIFY_READ, (void *)arg, size))

		return -EFAULT

	switch(cmd) {

	    case NEW_GETVALUE:

	        retval = __put_user(another_value,arg);

	        break;

	    case NEW_SETVALUE:

	        retval = __get_user(another_value,arg);

	        break;

	    }

	return retval;

	}

Another possibility is just stating "retval = 1"  and leaving the code

as shown,  but I don't like   the unadorned boolean  value. Naturally,

there are a lot of alternatives to this setup of ioctl().

----------------------------------------------------------------------

The following notes are about two differences between my intentions,

as stated in the printed book, and the actual outcome of the sample

files as you find them on the ftp site.

Allocating DMA memory

=====================

In  the section called "Allocating the  DMA buffer",  in chapter 13, I

refer   to  an  "allocator.c"   module,  which    performs  aggressive

allocation.  After using  such a module  in practice, I  found that it

didn't  get reliable results,    so  I dropped   it altogether.    The

implementation you find in the sample files (misc-modules/allocator.c)

uses high memory to allocate  the DMA buffer,  in the way explained in

the same section of chapter 13. misc-modules/README.allocator explains

the issue to a finer detail.

Decoding Oops messages

======================

The version of "oops"  you find on the ftp  site only decodes messages

generated on the  Intel platform. I didn't manage  to find the time to

implement it on the Alpha and the Sparc, as I intended to. As a matter

of fact, Oops messages on RISC platforms include less information than

Intel ones,  and they are harder to   use.

Unless  otherwise stated, the  source code distributed  with this book

can   be  redistributed in source    or  binary form   so  long  as an

acknowledgment  appears in derived source   files. The citation should

list  that the  code comes from  "Linux Device Drivers"  by Alessandro

Rubini,   published by   O'Reilly & Associates.  This    code is under 

copyright and  cannot be  included in any other book, publication,  or

educational product without permission from O'Reilly &  Associates. No

warranty  is  attached; we  cannot take responsibility   for errors or 

fitness for use.

There are  a  few exception to  this  licence, however:  a few sources

herein    are  distributed  according   to   the  GNU   General Public

License. You'll find a copy  of the license in /usr/src/linux/COPYING,

and in other places in your filesystem. The affected source files are:

 	pci/pcidata.c

 	pci/pciregions.c

	v2.1/pci/pcidata.c

	v2.1/pci/pciregions.c

	v2.1/misc-modules/allocator.c

The  files in ./pci and   ./v2.1/pci inherit the   GPL from the kernel

sources, as  some of their code comes  straight from the kernel; their

being GPL'd doesn't  prevent you from writing  binary modules,  as the

code in the pci* modules isn't meant to be included in custom drivers,

the modules are just standalone probing tools.

The allocator,  on the other hand,  is completely mine, but I'd better

not allow hiding code dealing  with memory management.  If you want to

use  the  allocator  in a  binary-only module,   just compile it  as a

standalone module and distribute its source.

Note  that   although everything here  is  designed  to allow building

binary modules, I'm strongly against this practice. All software in my

opinion should be  free (in the  sense  of freedom). Every Linux  user

should acknowledge the importance of the GPL and should use it for any

new software.

Enjoy

/alessandro

## Example files for the title:  

# Linux Device Drivers, by Alessandro Rubini

[![Linux Device Drivers, by Alessandro Rubini](http://akamaicovers.oreilly.com/images/9781565922921/cat.gif)](https://www.safaribooksonline.com/library/view/title/1565922921//)

The following applies to example files from material published by O’Reilly Media, Inc. Content from other publishers may include different rules of usage. Please refer to any additional usage rights explained in the actual example files or refer to the publisher’s website.

O'Reilly books are here to help you get your job done. In general, you may use the code in O'Reilly books in your programs and documentation. You do not need to contact us for permission unless you're reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from our books does not require permission. Answering a question by citing our books and quoting example code does not require permission. On the other hand, selling or distributing a CD-ROM of examples from O'Reilly books does require permission. Incorporating a significant amount of example code from our books into your product's documentation does require permission.

We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN.

If you think your use of code examples falls outside fair use or the permission given here, feel free to contact us at <permissions@oreilly.com>.

Please note that the examples are not production code and have not been carefully testing. They are provided "as-is" and come with no warranty of any kind.