Merge branch 'master'

     <title>Network device support</title>

     <title>Network device support</title>

     <sect1><title>Driver Support</title>

     <sect1><title>Driver Support</title>

!Enet/core/dev.c

!Enet/core/dev.c

     </sect1>

!Enet/ethernet/eth.c

     <sect1><title>8390 Based Network Cards</title>

!Einclude/linux/etherdevice.h

!Edrivers/net/8390.c

!Enet/core/wireless.c

     </sect1>

     </sect1>

     <sect1><title>Synchronous PPP</title>

     <sect1><title>Synchronous PPP</title>

!Edrivers/net/wan/syncppp.c

!Edrivers/net/wan/syncppp.c

RCU Torture Test Operation

CONFIG_RCU_TORTURE_TEST

The CONFIG_RCU_TORTURE_TEST config option is available for all RCU

implementations.  It creates an rcutorture kernel module that can

be loaded to run a torture test.  The test periodically outputs

status messages via printk(), which can be examined via the dmesg

command (perhaps grepping for "rcutorture").  The test is started

when the module is loaded, and stops when the module is unloaded.

However, actually setting this config option to "y" results in the system

running the test immediately upon boot, and ending only when the system

is taken down.  Normally, one will instead want to build the system

with CONFIG_RCU_TORTURE_TEST=m and to use modprobe and rmmod to control

the test, perhaps using a script similar to the one shown at the end of

this document.  Note that you will need CONFIG_MODULE_UNLOAD in order

to be able to end the test.

MODULE PARAMETERS

This module has the following parameters:

nreaders	This is the number of RCU reading threads supported.

		The default is twice the number of CPUs.  Why twice?

		To properly exercise RCU implementations with preemptible

		read-side critical sections.

stat_interval	The number of seconds between output of torture

		statistics (via printk()).  Regardless of the interval,

		statistics are printed when the module is unloaded.

		Setting the interval to zero causes the statistics to

		be printed -only- when the module is unloaded, and this

		is the default.

verbose		Enable debug printk()s.  Default is disabled.

OUTPUT

The statistics output is as follows:

	rcutorture: --- Start of test: nreaders=16 stat_interval=0 verbose=0

	rcutorture: rtc: 0000000000000000 ver: 1916 tfle: 0 rta: 1916 rtaf: 0 rtf: 1915

	rcutorture: Reader Pipe:  1466408 9747 0 0 0 0 0 0 0 0 0

	rcutorture: Reader Batch:  1464477 11678 0 0 0 0 0 0 0 0

	rcutorture: Free-Block Circulation:  1915 1915 1915 1915 1915 1915 1915 1915 1915 1915 0

	rcutorture: --- End of test

The command "dmesg | grep rcutorture:" will extract this information on

most systems.  On more esoteric configurations, it may be necessary to

use other commands to access the output of the printk()s used by

the RCU torture test.  The printk()s use KERN_ALERT, so they should

be evident.  ;-)

The entries are as follows:

o	"ggp": The number of counter flips (or batches) since boot.

o	"rtc": The hexadecimal address of the structure currently visible

	to readers.

o	"ver": The number of times since boot that the rcutw writer task

	has changed the structure visible to readers.

o	"tfle": If non-zero, indicates that the "torture freelist"

	containing structure to be placed into the "rtc" area is empty.

	This condition is important, since it can fool you into thinking

	that RCU is working when it is not.  :-/

o	"rta": Number of structures allocated from the torture freelist.

o	"rtaf": Number of allocations from the torture freelist that have

	failed due to the list being empty.

o	"rtf": Number of frees into the torture freelist.

o	"Reader Pipe": Histogram of "ages" of structures seen by readers.

	If any entries past the first two are non-zero, RCU is broken.

	And rcutorture prints the error flag string "!!!" to make sure

	you notice.  The age of a newly allocated structure is zero,

	it becomes one when removed from reader visibility, and is

	incremented once per grace period subsequently -- and is freed

	after passing through (RCU_TORTURE_PIPE_LEN-2) grace periods.

	The output displayed above was taken from a correctly working

	RCU.  If you want to see what it looks like when broken, break

	it yourself.  ;-)

o	"Reader Batch": Another histogram of "ages" of structures seen

	by readers, but in terms of counter flips (or batches) rather

	than in terms of grace periods.  The legal number of non-zero

	entries is again two.  The reason for this separate view is

	that it is easier to get the third entry to show up in the

	"Reader Batch" list than in the "Reader Pipe" list.

o	"Free-Block Circulation": Shows the number of torture structures

	that have reached a given point in the pipeline.  The first element

	should closely correspond to the number of structures allocated,

	the second to the number that have been removed from reader view,

	and all but the last remaining to the corresponding number of

	passes through a grace period.  The last entry should be zero,

	as it is only incremented if a torture structure's counter

	somehow gets incremented farther than it should.

USAGE

The following script may be used to torture RCU:

	#!/bin/sh

	modprobe rcutorture

	sleep 100

	rmmod rcutorture

	dmesg | grep rcutorture:

The output can be manually inspected for the error flag of "!!!".

One could of course create a more elaborate script that automatically

checked for such errors.

  Any large scale modifications, or new drivers should be discussed

  Any large scale modifications, or new drivers should be discussed

  on the ARM kernel mailing list (linux-arm-kernel) before being

  on the ARM kernel mailing list (linux-arm-kernel) before being

  attempted.

  attempted. See http://www.arm.linux.org.uk/mailinglists/ for the

  mailing list information.

NAND

NAND

  various clock units

  various clock units

Platform Data

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

  Whenever a device has platform specific data that is specified

  on a per-machine basis, care should be taken to ensure the

  following:

    1) that default data is not left in the device to confuse the

       driver if a machine does not set it at startup

    2) the data should (if possible) be marked as __initdata,

       to ensure that the data is thrown away if the machine is

       not the one currently in use.

       The best way of doing this is to make a function that

       kmalloc()s an area of memory, and copies the __initdata

       and then sets the relevant device's platform data. Making

       the function `__init` takes care of ensuring it is discarded

       with the rest of the initialisation code

       static __init void s3c24xx_xxx_set_platdata(struct xxx_data *pd)

       {

           struct s3c2410_xxx_mach_info *npd;

	   npd = kmalloc(sizeof(struct s3c2410_xxx_mach_info), GFP_KERNEL);

	   if (npd) {

	      memcpy(npd, pd, sizeof(struct s3c2410_xxx_mach_info));

	      s3c_device_xxx.dev.platform_data = npd;

	   } else {

              printk(KERN_ERR "no memory for xxx platform data\n");

	   }

	}

	Note, since the code is marked as __init, it should not be

	exported outside arch/arm/mach-s3c2410/, or exported to

	modules via EXPORT_SYMBOL() and related functions.

Port Contributors

Port Contributors

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

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

  06 Mar 2005 - BJD - Added Christer Weinigel

  06 Mar 2005 - BJD - Added Christer Weinigel

  08 Mar 2005 - BJD - Added LCVR to list of people, updated introduction

  08 Mar 2005 - BJD - Added LCVR to list of people, updated introduction

  08 Mar 2005 - BJD - Added section on adding machines

  08 Mar 2005 - BJD - Added section on adding machines

  09 Sep 2005 - BJD - Added section on platform data

Document Author

Document Author

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

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

But larger systems, which benefit more from careful processor and

But larger systems, which benefit more from careful processor and

memory placement to reduce memory access times and contention,

memory placement to reduce memory access times and contention,

and which typically represent a larger investment for the customer,

and which typically represent a larger investment for the customer,

can benefit from explictly placing jobs on properly sized subsets of

can benefit from explicitly placing jobs on properly sized subsets of

the system.

the system.

This can be especially valuable on:

This can be especially valuable on:

Features

Features

========

========

- This is a complete rewrite of the NTFS driver that used to be in the kernel.

- This is a complete rewrite of the NTFS driver that used to be in the 2.4 and

  This new driver implements NTFS read support and is functionally equivalent

  earlier kernels.  This new driver implements NTFS read support and is

  to the old ntfs driver.

  functionally equivalent to the old ntfs driver and it also implements limited

  write support.  The biggest limitation at present is that files/directories

  cannot be created or deleted.  See below for the list of write features that

  are so far supported.  Another limitation is that writing to compressed files

  is not implemented at all.  Also, neither read nor write access to encrypted

  files is so far implemented.

- The new driver has full support for sparse files on NTFS 3.x volumes which

- The new driver has full support for sparse files on NTFS 3.x volumes which

  the old driver isn't happy with.

  the old driver isn't happy with.

- The new driver supports execution of binaries due to mmap() now being

- The new driver supports execution of binaries due to mmap() now being

- The new driver supports fsync(2), fdatasync(2), and msync(2).

- The new driver supports fsync(2), fdatasync(2), and msync(2).

- The new driver supports readv(2) and writev(2).

- The new driver supports readv(2) and writev(2).

- The new driver supports access time updates (including mtime and ctime).

- The new driver supports access time updates (including mtime and ctime).

- The new driver supports truncate(2) and open(2) with O_TRUNC.  But at present

  only very limited support for highly fragmented files, i.e. ones which have

  their data attribute split across multiple extents, is included.  Another

  limitation is that at present truncate(2) will never create sparse files,

  since to mark a file sparse we need to modify the directory entry for the

  file and we do not implement directory modifications yet.

- The new driver supports write(2) which can both overwrite existing data and

  extend the file size so that you can write beyond the existing data.  Also,

  writing into sparse regions is supported and the holes are filled in with

  clusters.  But at present only limited support for highly fragmented files,

  i.e. ones which have their data attribute split across multiple extents, is

  included.  Another limitation is that write(2) will never create sparse

  files, since to mark a file sparse we need to modify the directory entry for

  the file and we do not implement directory modifications yet.

Supported mount options

Supported mount options

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

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

Note, a technical ChangeLog aimed at kernel hackers is in fs/ntfs/ChangeLog.

Note, a technical ChangeLog aimed at kernel hackers is in fs/ntfs/ChangeLog.

2.1.25:

	- Write support is now extended with write(2) being able to both

	  overwrite existing file data and to extend files.  Also, if a write

	  to a sparse region occurs, write(2) will fill in the hole.  Note,

	  mmap(2) based writes still do not support writing into holes or

	  writing beyond the initialized size.

	- Write support has a new feature and that is that truncate(2) and

	  open(2) with O_TRUNC are now implemented thus files can be both made

	  smaller and larger.

	- Note: Both write(2) and truncate(2)/open(2) with O_TRUNC still have

	  limitations in that they

	  - only provide limited support for highly fragmented files.

	  - only work on regular, i.e. uncompressed and unencrypted files.

	  - never create sparse files although this will change once directory

	    operations are implemented.

	- Lots of bug fixes and enhancements across the board.

2.1.24:

2.1.24:

	- Support journals ($LogFile) which have been modified by chkdsk.  This

	- Support journals ($LogFile) which have been modified by chkdsk.  This

	  means users can boot into Windows after we marked the volume dirty.

	  means users can boot into Windows after we marked the volume dirty.