Merge master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6
authorDavid S. Miller <davem@outer-richmond.davemloft.net>
Sat, 10 Sep 2005 07:01:36 +0000 (00:01 -0700)
committerDavid S. Miller <davem@outer-richmond.davemloft.net>
Sat, 10 Sep 2005 07:01:36 +0000 (00:01 -0700)
637 files changed:
Documentation/00-INDEX
Documentation/DMA-ISA-LPC.txt [new file with mode: 0644]
Documentation/DocBook/kernel-hacking.tmpl
Documentation/RCU/rcuref.txt [new file with mode: 0644]
Documentation/applying-patches.txt [new file with mode: 0644]
Documentation/dvb/bt8xx.txt
Documentation/dvb/ci.txt
Documentation/fb/cyblafb/bugs [new file with mode: 0644]
Documentation/fb/cyblafb/credits [new file with mode: 0644]
Documentation/fb/cyblafb/documentation [new file with mode: 0644]
Documentation/fb/cyblafb/fb.modes [new file with mode: 0644]
Documentation/fb/cyblafb/performance [new file with mode: 0644]
Documentation/fb/cyblafb/todo [new file with mode: 0644]
Documentation/fb/cyblafb/usage [new file with mode: 0644]
Documentation/fb/cyblafb/whycyblafb [new file with mode: 0644]
Documentation/fb/modedb.txt
Documentation/filesystems/files.txt [new file with mode: 0644]
Documentation/filesystems/fuse.txt [new file with mode: 0644]
Documentation/filesystems/proc.txt
Documentation/filesystems/v9fs.txt [new file with mode: 0644]
Documentation/filesystems/vfs.txt
Documentation/kdump/kdump.txt
Documentation/sparse.txt
Documentation/video4linux/CARDLIST.bttv
Documentation/video4linux/CARDLIST.saa7134
Documentation/video4linux/CARDLIST.tuner
Kbuild [new file with mode: 0644]
MAINTAINERS
Makefile
arch/alpha/Makefile
arch/alpha/kernel/entry.S
arch/alpha/kernel/head.S
arch/alpha/kernel/module.c
arch/alpha/kernel/osf_sys.c
arch/alpha/lib/dbg_stackcheck.S
arch/alpha/lib/dbg_stackkill.S
arch/arm/Makefile
arch/arm/kernel/entry-header.S
arch/arm/kernel/head.S
arch/arm/kernel/iwmmxt.S
arch/arm/lib/copy_page.S
arch/arm/lib/csumpartialcopyuser.S
arch/arm/lib/getuser.S
arch/arm/lib/putuser.S
arch/arm/mach-pxa/corgi_ssp.c
arch/arm/mach-s3c2410/devs.c
arch/arm/mach-s3c2410/mach-h1940.c
arch/arm/mm/copypage-v3.S
arch/arm/mm/copypage-v4wb.S
arch/arm/mm/copypage-v4wt.S
arch/arm/mm/proc-arm1020.S
arch/arm/mm/proc-arm1020e.S
arch/arm/mm/proc-arm1022.S
arch/arm/mm/proc-arm1026.S
arch/arm/mm/proc-arm6_7.S
arch/arm/mm/proc-arm720.S
arch/arm/mm/proc-macros.S
arch/arm/mm/proc-sa110.S
arch/arm/mm/proc-sa1100.S
arch/arm/mm/proc-v6.S
arch/arm/mm/tlb-v3.S
arch/arm/mm/tlb-v4.S
arch/arm/mm/tlb-v4wb.S
arch/arm/mm/tlb-v4wbi.S
arch/arm/mm/tlb-v6.S
arch/arm/nwfpe/entry26.S
arch/arm/vfp/entry.S
arch/arm26/Makefile
arch/arm26/kernel/entry.S
arch/arm26/lib/copy_page.S
arch/arm26/lib/csumpartialcopyuser.S
arch/arm26/lib/getuser.S
arch/arm26/lib/putuser.S
arch/arm26/mm/proc-funcs.S
arch/arm26/nwfpe/entry.S
arch/cris/Makefile
arch/cris/arch-v10/kernel/entry.S
arch/cris/arch-v32/kernel/entry.S
arch/frv/kernel/asm-offsets.c [new file with mode: 0644]
arch/h8300/Makefile
arch/i386/Makefile
arch/i386/boot/video.S
arch/i386/kernel/head.S
arch/i386/kernel/mpparse.c
arch/i386/kernel/ptrace.c
arch/i386/kernel/setup.c
arch/i386/kernel/time.c
arch/i386/kernel/vsyscall-sigreturn.S
arch/i386/kernel/vsyscall.lds.S
arch/i386/power/swsusp.S
arch/ia64/Makefile
arch/ia64/ia32/ia32_entry.S
arch/ia64/kernel/entry.S
arch/ia64/kernel/fsys.S
arch/ia64/kernel/gate.S
arch/ia64/kernel/head.S
arch/ia64/kernel/ivt.S
arch/ia64/kernel/perfmon.c
arch/ia64/sn/kernel/xpnet.c
arch/m32r/kernel/asm-offsets.c [new file with mode: 0644]
arch/m68k/Makefile
arch/m68k/amiga/amisound.c
arch/m68k/fpsp040/skeleton.S
arch/m68k/ifpsp060/iskeleton.S
arch/m68k/kernel/entry.S
arch/m68k/kernel/head.S
arch/m68k/mac/macboing.c
arch/m68k/math-emu/fp_emu.h
arch/m68knommu/Makefile
arch/mips/Kconfig
arch/mips/Makefile
arch/mips/configs/tb0287_defconfig [new file with mode: 0644]
arch/mips/kernel/genrtc.c
arch/mips/kernel/i8259.c
arch/mips/kernel/irixioctl.c
arch/mips/kernel/r2300_fpu.S
arch/mips/kernel/r2300_switch.S
arch/mips/kernel/r4k_fpu.S
arch/mips/kernel/r4k_switch.S
arch/mips/kernel/r6000_fpu.S
arch/mips/kernel/scall32-o32.S
arch/mips/kernel/scall64-64.S
arch/mips/kernel/syscall.c
arch/mips/lib-32/memset.S
arch/mips/lib-64/memset.S
arch/mips/lib/memcpy.S
arch/mips/lib/strlen_user.S
arch/mips/lib/strncpy_user.S
arch/mips/lib/strnlen_user.S
arch/mips/pci/Makefile
arch/mips/pci/fixup-tb0287.c [new file with mode: 0644]
arch/parisc/Makefile
arch/parisc/hpux/gate.S
arch/parisc/hpux/wrappers.S
arch/parisc/kernel/entry.S
arch/parisc/kernel/head.S
arch/parisc/kernel/process.c
arch/parisc/kernel/ptrace.c
arch/parisc/kernel/signal.c
arch/parisc/kernel/syscall.S
arch/parisc/lib/fixup.S
arch/ppc/8xx_io/cs4218_tdm.c
arch/ppc/Kconfig
arch/ppc/Makefile
arch/ppc/boot/common/ns16550.c
arch/ppc/boot/common/util.S
arch/ppc/kernel/Makefile
arch/ppc/kernel/cpu_setup_6xx.S
arch/ppc/kernel/cpu_setup_power4.S
arch/ppc/kernel/entry.S
arch/ppc/kernel/fpu.S
arch/ppc/kernel/head.S
arch/ppc/kernel/head_44x.S
arch/ppc/kernel/head_4xx.S
arch/ppc/kernel/head_8xx.S
arch/ppc/kernel/head_fsl_booke.S
arch/ppc/kernel/idle_6xx.S
arch/ppc/kernel/idle_power4.S
arch/ppc/kernel/misc.S
arch/ppc/kernel/swsusp.S
arch/ppc/kernel/traps.c
arch/ppc/mm/hashtable.S
arch/ppc/platforms/4xx/ebony.c
arch/ppc/platforms/hdpu.c
arch/ppc/platforms/pmac_sleep.S
arch/ppc/syslib/ibm440gx_common.c
arch/ppc/syslib/mv64x60.c
arch/ppc/syslib/qspan_pci.c
arch/ppc64/Makefile
arch/ppc64/kernel/cpu_setup_power4.S
arch/ppc64/kernel/entry.S
arch/ppc64/kernel/head.S
arch/ppc64/kernel/idle_power4.S
arch/ppc64/kernel/misc.S
arch/ppc64/kernel/pmc.c
arch/ppc64/kernel/vdso32/cacheflush.S
arch/ppc64/kernel/vdso32/datapage.S
arch/ppc64/kernel/vdso32/gettimeofday.S
arch/ppc64/kernel/vdso64/cacheflush.S
arch/ppc64/kernel/vdso64/datapage.S
arch/ppc64/kernel/vdso64/gettimeofday.S
arch/ppc64/mm/hash_low.S
arch/ppc64/mm/slb_low.S
arch/s390/Makefile
arch/s390/kernel/entry.S
arch/s390/kernel/entry64.S
arch/s390/kernel/head.S
arch/s390/kernel/head64.S
arch/s390/lib/uaccess.S
arch/s390/lib/uaccess64.S
arch/sh/Makefile
arch/sh64/Makefile
arch/sparc/Makefile
arch/sparc/kernel/entry.S
arch/sparc/kernel/sclow.S
arch/sparc/lib/atomic32.c
arch/sparc/mm/hypersparc.S
arch/sparc/mm/swift.S
arch/sparc/mm/tsunami.S
arch/sparc/mm/viking.S
arch/sparc64/kernel/asm-offsets.c [new file with mode: 0644]
arch/sparc64/solaris/ioctl.c
arch/sparc64/solaris/timod.c
arch/um/Makefile
arch/um/kernel/asm-offsets.c [new file with mode: 0644]
arch/v850/Makefile
arch/v850/kernel/asm-offsets.c [moved from arch/v850/kernel/asm-consts.c with 100% similarity]
arch/v850/kernel/entry.S
arch/x86_64/Makefile
arch/x86_64/ia32/ia32_ioctl.c
arch/x86_64/ia32/ia32entry.S
arch/x86_64/ia32/vsyscall-syscall.S
arch/x86_64/ia32/vsyscall-sysenter.S
arch/x86_64/kernel/e820.c
arch/x86_64/kernel/entry.S
arch/x86_64/kernel/genapic_flat.c
arch/x86_64/kernel/smpboot.c
arch/x86_64/kernel/suspend_asm.S
arch/x86_64/lib/copy_user.S
arch/x86_64/lib/getuser.S
arch/x86_64/lib/putuser.S
arch/xtensa/Makefile
arch/xtensa/kernel/align.S
arch/xtensa/kernel/entry.S
arch/xtensa/kernel/process.c
arch/xtensa/kernel/vectors.S
drivers/acorn/block/fd1772.c
drivers/atm/idt77105.c
drivers/atm/iphase.c
drivers/block/acsi.c
drivers/block/acsi_slm.c
drivers/block/ataflop.c
drivers/block/deadline-iosched.c
drivers/block/floppy.c
drivers/block/ps2esdi.c
drivers/cdrom/aztcd.c
drivers/cdrom/gscd.c
drivers/cdrom/optcd.c
drivers/cdrom/sbpcd.c
drivers/cdrom/sjcd.c
drivers/char/cyclades.c
drivers/char/hangcheck-timer.c
drivers/char/ip2main.c
drivers/char/ipmi/ipmi_devintf.c
drivers/char/istallion.c
drivers/char/keyboard.c
drivers/char/pty.c
drivers/char/synclink.c
drivers/char/synclinkmp.c
drivers/char/tty_io.c
drivers/char/vt.c
drivers/char/watchdog/mixcomwd.c
drivers/ide/legacy/ide-cs.c
drivers/ieee1394/video1394.c
drivers/input/evdev.c
drivers/md/bitmap.c
drivers/md/dm-raid1.c
drivers/md/linear.c
drivers/md/md.c
drivers/md/multipath.c
drivers/md/raid0.c
drivers/md/raid1.c
drivers/md/raid10.c
drivers/md/raid5.c
drivers/md/raid6main.c
drivers/media/Makefile
drivers/media/common/ir-common.c
drivers/media/common/saa7146_fops.c
drivers/media/common/saa7146_i2c.c
drivers/media/dvb/b2c2/flexcop-fe-tuner.c
drivers/media/dvb/bt8xx/bt878.c
drivers/media/dvb/bt8xx/bt878.h
drivers/media/dvb/bt8xx/dst.c
drivers/media/dvb/bt8xx/dst_ca.c
drivers/media/dvb/bt8xx/dst_common.h
drivers/media/dvb/bt8xx/dvb-bt8xx.c
drivers/media/dvb/bt8xx/dvb-bt8xx.h
drivers/media/dvb/cinergyT2/Kconfig
drivers/media/dvb/cinergyT2/cinergyT2.c
drivers/media/dvb/dvb-core/demux.h
drivers/media/dvb/dvb-core/dmxdev.c
drivers/media/dvb/dvb-core/dvb_ca_en50221.c
drivers/media/dvb/dvb-core/dvb_demux.c
drivers/media/dvb/dvb-core/dvb_demux.h
drivers/media/dvb/dvb-core/dvb_net.c
drivers/media/dvb/dvb-usb/Kconfig
drivers/media/dvb/dvb-usb/Makefile
drivers/media/dvb/dvb-usb/a800.c
drivers/media/dvb/dvb-usb/cxusb.c
drivers/media/dvb/dvb-usb/cxusb.h
drivers/media/dvb/dvb-usb/dibusb-mb.c
drivers/media/dvb/dvb-usb/dibusb-mc.c
drivers/media/dvb/dvb-usb/digitv.c
drivers/media/dvb/dvb-usb/dtt200u-fe.c
drivers/media/dvb/dvb-usb/dtt200u.c
drivers/media/dvb/dvb-usb/dvb-usb-ids.h
drivers/media/dvb/dvb-usb/dvb-usb-init.c
drivers/media/dvb/dvb-usb/dvb-usb.h
drivers/media/dvb/dvb-usb/nova-t-usb2.c
drivers/media/dvb/dvb-usb/umt-010.c
drivers/media/dvb/dvb-usb/vp702x-fe.c [new file with mode: 0644]
drivers/media/dvb/dvb-usb/vp702x.c [new file with mode: 0644]
drivers/media/dvb/dvb-usb/vp702x.h [new file with mode: 0644]
drivers/media/dvb/dvb-usb/vp7045.c
drivers/media/dvb/frontends/cx24110.c
drivers/media/dvb/frontends/cx24110.h
drivers/media/dvb/frontends/dib3000mb.c
drivers/media/dvb/frontends/dib3000mc.c
drivers/media/dvb/frontends/mt352.c
drivers/media/dvb/frontends/nxt6000.c
drivers/media/dvb/frontends/or51132.c
drivers/media/dvb/frontends/s5h1420.c
drivers/media/dvb/frontends/s5h1420.h
drivers/media/dvb/frontends/stv0297.c
drivers/media/dvb/frontends/stv0297.h
drivers/media/dvb/frontends/stv0299.c
drivers/media/dvb/frontends/stv0299.h
drivers/media/dvb/frontends/tda1004x.c
drivers/media/dvb/frontends/ves1820.c
drivers/media/dvb/ttpci/av7110.c
drivers/media/dvb/ttpci/av7110.h
drivers/media/dvb/ttpci/av7110_hw.c
drivers/media/dvb/ttpci/av7110_ir.c
drivers/media/dvb/ttpci/av7110_v4l.c
drivers/media/dvb/ttpci/budget-av.c
drivers/media/dvb/ttpci/budget-ci.c
drivers/media/dvb/ttpci/budget-patch.c
drivers/media/dvb/ttpci/budget.c
drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c
drivers/media/dvb/ttusb-dec/ttusb_dec.c
drivers/media/video/Kconfig
drivers/media/video/Makefile
drivers/media/video/btcx-risc.c
drivers/media/video/btcx-risc.h
drivers/media/video/bttv-cards.c
drivers/media/video/bttv-driver.c
drivers/media/video/bttv-gpio.c
drivers/media/video/bttv-i2c.c
drivers/media/video/bttv-if.c
drivers/media/video/bttv-risc.c
drivers/media/video/bttv-vbi.c
drivers/media/video/bttv.h
drivers/media/video/bttvp.h
drivers/media/video/cx88/cx88-blackbird.c
drivers/media/video/cx88/cx88-cards.c
drivers/media/video/cx88/cx88-core.c
drivers/media/video/cx88/cx88-dvb.c
drivers/media/video/cx88/cx88-i2c.c
drivers/media/video/cx88/cx88-input.c
drivers/media/video/cx88/cx88-mpeg.c
drivers/media/video/cx88/cx88-reg.h
drivers/media/video/cx88/cx88-tvaudio.c
drivers/media/video/cx88/cx88-vbi.c
drivers/media/video/cx88/cx88-video.c
drivers/media/video/cx88/cx88.h
drivers/media/video/ir-kbd-gpio.c
drivers/media/video/ir-kbd-i2c.c
drivers/media/video/msp3400.c
drivers/media/video/msp3400.h
drivers/media/video/mt20xx.c
drivers/media/video/rds.h [new file with mode: 0644]
drivers/media/video/saa6588.c [new file with mode: 0644]
drivers/media/video/saa7134/saa7134-cards.c
drivers/media/video/saa7134/saa7134-core.c
drivers/media/video/saa7134/saa7134-dvb.c
drivers/media/video/saa7134/saa7134-empress.c
drivers/media/video/saa7134/saa7134-i2c.c
drivers/media/video/saa7134/saa7134-input.c
drivers/media/video/saa7134/saa7134-oss.c
drivers/media/video/saa7134/saa7134-reg.h
drivers/media/video/saa7134/saa7134-ts.c
drivers/media/video/saa7134/saa7134-tvaudio.c
drivers/media/video/saa7134/saa7134-vbi.c
drivers/media/video/saa7134/saa7134-video.c
drivers/media/video/saa7134/saa7134.h
drivers/media/video/tda8290.c
drivers/media/video/tda9887.c
drivers/media/video/tea5767.c
drivers/media/video/tuner-core.c
drivers/media/video/tuner-simple.c
drivers/media/video/tvaudio.c
drivers/media/video/tveeprom.c
drivers/media/video/tvmixer.c
drivers/media/video/v4l1-compat.c
drivers/media/video/v4l2-common.c
drivers/media/video/video-buf-dvb.c
drivers/media/video/video-buf.c
drivers/net/atari_bionet.c
drivers/net/atari_pamsnet.c
drivers/net/cris/eth_v10.c
drivers/net/cs89x0.c
drivers/net/hamradio/yam.c
drivers/net/mv643xx_eth.c
drivers/parisc/iosapic.c
drivers/pci/hotplug.c
drivers/pci/hotplug/pciehprm_acpi.c
drivers/pci/pci.h
drivers/pci/probe.c
drivers/pci/quirks.c
drivers/pci/setup-bus.c
drivers/pcmcia/Kconfig
drivers/pcmcia/Makefile
drivers/pcmcia/cs.c
drivers/pcmcia/cs_internal.h
drivers/pcmcia/ds.c
drivers/pcmcia/omap_cf.c [new file with mode: 0644]
drivers/pcmcia/pcmcia_resource.c
drivers/pcmcia/yenta_socket.c
drivers/sbus/char/aurora.c
drivers/scsi/ch.c
drivers/scsi/pluto.c
drivers/scsi/qla2xxx/qla_dbg.c
drivers/serial/serial_txx9.c
drivers/usb/host/hc_crisv10.c
drivers/video/Kconfig
drivers/video/Makefile
drivers/video/aty/aty128fb.c
drivers/video/aty/atyfb_base.c
drivers/video/aty/radeon_base.c
drivers/video/console/bitblit.c
drivers/video/console/fbcon.c
drivers/video/console/fbcon.h
drivers/video/console/vgacon.c
drivers/video/cyblafb.c [new file with mode: 0644]
drivers/video/fbcvt.c [new file with mode: 0644]
drivers/video/fbmem.c
drivers/video/fbmon.c
drivers/video/geode/Kconfig
drivers/video/geode/display_gx1.c
drivers/video/geode/geodefb.h
drivers/video/geode/gx1fb_core.c
drivers/video/geode/video_cs5530.c
drivers/video/i810/Makefile
drivers/video/i810/i810-i2c.c [new file with mode: 0644]
drivers/video/i810/i810.h
drivers/video/i810/i810_main.c
drivers/video/i810/i810_main.h
drivers/video/intelfb/intelfb.h
drivers/video/intelfb/intelfbdrv.c
drivers/video/intelfb/intelfbhw.c
drivers/video/matrox/matroxfb_misc.c
drivers/video/modedb.c
drivers/video/nvidia/nv_i2c.c
drivers/video/nvidia/nv_local.h
drivers/video/nvidia/nv_proto.h
drivers/video/nvidia/nv_setup.c
drivers/video/nvidia/nvidia.c
drivers/video/pxafb.c
drivers/video/pxafb.h
drivers/video/s3c2410fb.c [new file with mode: 0644]
drivers/video/s3c2410fb.h [new file with mode: 0644]
drivers/video/savage/savagefb-i2c.c
drivers/video/savage/savagefb.h
drivers/video/savage/savagefb_driver.c
drivers/video/sis/300vtbl.h
drivers/video/sis/310vtbl.h
drivers/video/sis/Makefile
drivers/video/sis/init.c
drivers/video/sis/init.h
drivers/video/sis/init301.c
drivers/video/sis/init301.h
drivers/video/sis/initdef.h
drivers/video/sis/initextlfb.c [new file with mode: 0644]
drivers/video/sis/oem300.h
drivers/video/sis/oem310.h
drivers/video/sis/osdef.h
drivers/video/sis/sis.h
drivers/video/sis/sis_accel.c
drivers/video/sis/sis_accel.h
drivers/video/sis/sis_main.c
drivers/video/sis/sis_main.h
drivers/video/sis/vgatypes.h
drivers/video/sis/vstruct.h
drivers/video/tridentfb.c
drivers/video/vesafb.c
fs/9p/9p.c [new file with mode: 0644]
fs/9p/9p.h [new file with mode: 0644]
fs/9p/Makefile [new file with mode: 0644]
fs/9p/conv.c [new file with mode: 0644]
fs/9p/conv.h [new file with mode: 0644]
fs/9p/debug.h [new file with mode: 0644]
fs/9p/error.c [new file with mode: 0644]
fs/9p/error.h [new file with mode: 0644]
fs/9p/fid.c [new file with mode: 0644]
fs/9p/fid.h [new file with mode: 0644]
fs/9p/mux.c [new file with mode: 0644]
fs/9p/mux.h [new file with mode: 0644]
fs/9p/trans_fd.c [new file with mode: 0644]
fs/9p/trans_sock.c [new file with mode: 0644]
fs/9p/transport.h [new file with mode: 0644]
fs/9p/v9fs.c [new file with mode: 0644]
fs/9p/v9fs.h [new file with mode: 0644]
fs/9p/v9fs_vfs.h [new file with mode: 0644]
fs/9p/vfs_dentry.c [new file with mode: 0644]
fs/9p/vfs_dir.c [new file with mode: 0644]
fs/9p/vfs_file.c [new file with mode: 0644]
fs/9p/vfs_inode.c [new file with mode: 0644]
fs/9p/vfs_super.c [new file with mode: 0644]
fs/Kconfig
fs/Makefile
fs/affs/inode.c
fs/aio.c
fs/autofs/autofs_i.h
fs/autofs/dirhash.c
fs/autofs/inode.c
fs/bfs/bfs.h
fs/bfs/dir.c
fs/bfs/file.c
fs/bfs/inode.c
fs/compat.c
fs/compat_ioctl.c
fs/exec.c
fs/ext2/ialloc.c
fs/ext2/inode.c
fs/ext2/xattr.h
fs/ext2/xattr_security.c
fs/ext3/ialloc.c
fs/ext3/inode.c
fs/ext3/xattr.h
fs/ext3/xattr_security.c
fs/fat/inode.c
fs/fcntl.c
fs/file.c
fs/file_table.c
fs/fuse/Makefile [new file with mode: 0644]
fs/fuse/dev.c [new file with mode: 0644]
fs/fuse/dir.c [new file with mode: 0644]
fs/fuse/file.c [new file with mode: 0644]
fs/fuse/fuse_i.h [new file with mode: 0644]
fs/fuse/inode.c [new file with mode: 0644]
fs/hostfs/hostfs_kern.c
fs/hpfs/inode.c
fs/inode.c
fs/jffs/inode-v23.c
fs/jfs/inode.c
fs/locks.c
fs/minix/inode.c
fs/namei.c
fs/ncpfs/inode.c
fs/nfs/inode.c
fs/open.c
fs/proc/array.c
fs/proc/base.c
fs/proc/inode.c
fs/qnx4/inode.c
fs/reiserfs/inode.c
fs/select.c
fs/smbfs/inode.c
fs/sysv/inode.c
fs/udf/inode.c
fs/ufs/inode.c
fs/xfs/support/ktrace.c
include/asm-arm/arch-pxa/pxafb.h
include/asm-arm/arch-s3c2410/fb.h [new file with mode: 0644]
include/asm-arm/arch-s3c2410/regs-lcd.h
include/asm-i386/mach-default/mach_reboot.h
include/asm-i386/mmzone.h
include/asm-i386/thread_info.h
include/asm-ia64/ptrace.h
include/asm-ia64/system.h
include/asm-ia64/thread_info.h
include/asm-mips/asmmacro-32.h
include/asm-mips/asmmacro-64.h
include/asm-mips/irq.h
include/asm-mips/sim.h
include/asm-mips/stackframe.h
include/asm-mips/vr41xx/tb0287.h [new file with mode: 0644]
include/asm-parisc/assembly.h
include/asm-ppc/irq.h
include/asm-ppc/reg.h
include/asm-sh/irq.h
include/asm-sparc/ptrace.h
include/asm-x86_64/current.h
include/asm-x86_64/irq.h
include/asm-xtensa/ptrace.h
include/asm-xtensa/uaccess.h
include/linux/bfs_fs.h
include/linux/fb.h
include/linux/file.h
include/linux/fs.h
include/linux/fuse.h [new file with mode: 0644]
include/linux/init_task.h
include/linux/pci.h
include/linux/raid/bitmap.h
include/linux/raid/linear.h
include/linux/raid/md_k.h
include/linux/raid/md_p.h
include/linux/raid/raid1.h
include/linux/raid/raid5.h
include/linux/rcupdate.h
include/linux/rcuref.h [new file with mode: 0644]
include/linux/sched.h
include/linux/security.h
include/linux/timer.h
include/linux/tty.h
include/linux/videodev.h
include/linux/videodev2.h
include/media/audiochip.h
include/media/id.h
include/media/ir-common.h
include/media/saa7146.h
include/media/tuner.h
include/media/tveeprom.h
include/media/video-buf.h
include/pcmcia/ds.h
include/sound/pcm.h
include/sound/tea575x-tuner.h
include/video/cyblafb.h [new file with mode: 0644]
include/video/sisfb.h
kernel/cpuset.c
kernel/exit.c
kernel/fork.c
kernel/rcupdate.c
kernel/sched.c
mm/page-writeback.c
mm/shmem.c
mm/slab.c
mm/vmalloc.c
net/atm/mpc.c
net/core/dst.c
net/core/netpoll.c
net/core/pktgen.c
net/decnet/dn_route.c
net/ipv4/inetpeer.c
net/ipv4/netfilter/ipt_owner.c
net/ipv6/addrconf.c
net/ipv6/ip6_fib.c
net/ipv6/ip6_flowlabel.c
net/ipv6/netfilter/ip6t_owner.c
net/netrom/nr_loopback.c
net/sched/sch_api.c
security/dummy.c
security/selinux/hooks.c
sound/oss/midibuf.c
sound/oss/soundcard.c
sound/oss/sys_timer.c
sound/oss/uart6850.c

index f28a24e0279b4c01aa8596e3f296ec50ef0ad70a..f6de52b010591120e0acb63791e24df45cfaed74 100644 (file)
@@ -46,6 +46,8 @@ SubmittingPatches
        - procedure to get a source patch included into the kernel tree.
 VGA-softcursor.txt
        - how to change your VGA cursor from a blinking underscore.
+applying-patches.txt
+       - description of various trees and how to apply their patches.
 arm/
        - directory with info about Linux on the ARM architecture.
 basic_profiling.txt
diff --git a/Documentation/DMA-ISA-LPC.txt b/Documentation/DMA-ISA-LPC.txt
new file mode 100644 (file)
index 0000000..705f6be
--- /dev/null
@@ -0,0 +1,151 @@
+                        DMA with ISA and LPC devices
+                        ============================
+
+                      Pierre Ossman <drzeus@drzeus.cx>
+
+This document describes how to do DMA transfers using the old ISA DMA
+controller. Even though ISA is more or less dead today the LPC bus
+uses the same DMA system so it will be around for quite some time.
+
+Part I - Headers and dependencies
+---------------------------------
+
+To do ISA style DMA you need to include two headers:
+
+#include <linux/dma-mapping.h>
+#include <asm/dma.h>
+
+The first is the generic DMA API used to convert virtual addresses to
+physical addresses (see Documentation/DMA-API.txt for details).
+
+The second contains the routines specific to ISA DMA transfers. Since
+this is not present on all platforms make sure you construct your
+Kconfig to be dependent on ISA_DMA_API (not ISA) so that nobody tries
+to build your driver on unsupported platforms.
+
+Part II - Buffer allocation
+---------------------------
+
+The ISA DMA controller has some very strict requirements on which
+memory it can access so extra care must be taken when allocating
+buffers.
+
+(You usually need a special buffer for DMA transfers instead of
+transferring directly to and from your normal data structures.)
+
+The DMA-able address space is the lowest 16 MB of _physical_ memory.
+Also the transfer block may not cross page boundaries (which are 64
+or 128 KiB depending on which channel you use).
+
+In order to allocate a piece of memory that satisfies all these
+requirements you pass the flag GFP_DMA to kmalloc.
+
+Unfortunately the memory available for ISA DMA is scarce so unless you
+allocate the memory during boot-up it's a good idea to also pass
+__GFP_REPEAT and __GFP_NOWARN to make the allocater try a bit harder.
+
+(This scarcity also means that you should allocate the buffer as
+early as possible and not release it until the driver is unloaded.)
+
+Part III - Address translation
+------------------------------
+
+To translate the virtual address to a physical use the normal DMA
+API. Do _not_ use isa_virt_to_phys() even though it does the same
+thing. The reason for this is that the function isa_virt_to_phys()
+will require a Kconfig dependency to ISA, not just ISA_DMA_API which
+is really all you need. Remember that even though the DMA controller
+has its origins in ISA it is used elsewhere.
+
+Note: x86_64 had a broken DMA API when it came to ISA but has since
+been fixed. If your arch has problems then fix the DMA API instead of
+reverting to the ISA functions.
+
+Part IV - Channels
+------------------
+
+A normal ISA DMA controller has 8 channels. The lower four are for
+8-bit transfers and the upper four are for 16-bit transfers.
+
+(Actually the DMA controller is really two separate controllers where
+channel 4 is used to give DMA access for the second controller (0-3).
+This means that of the four 16-bits channels only three are usable.)
+
+You allocate these in a similar fashion as all basic resources:
+
+extern int request_dma(unsigned int dmanr, const char * device_id);
+extern void free_dma(unsigned int dmanr);
+
+The ability to use 16-bit or 8-bit transfers is _not_ up to you as a
+driver author but depends on what the hardware supports. Check your
+specs or test different channels.
+
+Part V - Transfer data
+----------------------
+
+Now for the good stuff, the actual DMA transfer. :)
+
+Before you use any ISA DMA routines you need to claim the DMA lock
+using claim_dma_lock(). The reason is that some DMA operations are
+not atomic so only one driver may fiddle with the registers at a
+time.
+
+The first time you use the DMA controller you should call
+clear_dma_ff(). This clears an internal register in the DMA
+controller that is used for the non-atomic operations. As long as you
+(and everyone else) uses the locking functions then you only need to
+reset this once.
+
+Next, you tell the controller in which direction you intend to do the
+transfer using set_dma_mode(). Currently you have the options
+DMA_MODE_READ and DMA_MODE_WRITE.
+
+Set the address from where the transfer should start (this needs to
+be 16-bit aligned for 16-bit transfers) and how many bytes to
+transfer. Note that it's _bytes_. The DMA routines will do all the
+required translation to values that the DMA controller understands.
+
+The final step is enabling the DMA channel and releasing the DMA
+lock.
+
+Once the DMA transfer is finished (or timed out) you should disable
+the channel again. You should also check get_dma_residue() to make
+sure that all data has been transfered.
+
+Example:
+
+int flags, residue;
+
+flags = claim_dma_lock();
+
+clear_dma_ff();
+
+set_dma_mode(channel, DMA_MODE_WRITE);
+set_dma_addr(channel, phys_addr);
+set_dma_count(channel, num_bytes);
+
+dma_enable(channel);
+
+release_dma_lock(flags);
+
+while (!device_done());
+
+flags = claim_dma_lock();
+
+dma_disable(channel);
+
+residue = dma_get_residue(channel);
+if (residue != 0)
+       printk(KERN_ERR "driver: Incomplete DMA transfer!"
+               " %d bytes left!\n", residue);
+
+release_dma_lock(flags);
+
+Part VI - Suspend/resume
+------------------------
+
+It is the driver's responsibility to make sure that the machine isn't
+suspended while a DMA transfer is in progress. Also, all DMA settings
+are lost when the system suspends so if your driver relies on the DMA
+controller being in a certain state then you have to restore these
+registers upon resume.
index 49a9ef82d575fe99c60fe1ad4b382cf221a2ce86..6367bba32d22256dae461b2649c3f51367af93bc 100644 (file)
@@ -8,8 +8,7 @@
   
   <authorgroup>
    <author>
-    <firstname>Paul</firstname>
-    <othername>Rusty</othername>
+    <firstname>Rusty</firstname>
     <surname>Russell</surname>
     <affiliation>
      <address>
@@ -20,7 +19,7 @@
   </authorgroup>
 
   <copyright>
-   <year>2001</year>
+   <year>2005</year>
    <holder>Rusty Russell</holder>
   </copyright>
 
@@ -64,7 +63,7 @@
  <chapter id="introduction">
   <title>Introduction</title>
   <para>
-   Welcome, gentle reader, to Rusty's Unreliable Guide to Linux
+   Welcome, gentle reader, to Rusty's Remarkably Unreliable Guide to Linux
    Kernel Hacking.  This document describes the common routines and
    general requirements for kernel code: its goal is to serve as a
    primer for Linux kernel development for experienced C
 
    <listitem>
     <para>
-     not associated with any process, serving a softirq, tasklet or bh;
+     not associated with any process, serving a softirq or tasklet;
     </para>
    </listitem>
 
    <listitem>
     <para>
-     running in kernel space, associated with a process;
+     running in kernel space, associated with a process (user context);
     </para>
    </listitem>
 
   </itemizedlist>
 
   <para>
-   There is a strict ordering between these: other than the last
-   category (userspace) each can only be pre-empted by those above.
-   For example, while a softirq is running on a CPU, no other
-   softirq will pre-empt it, but a hardware interrupt can.  However,
-   any other CPUs in the system execute independently.
+   There is an ordering between these.  The bottom two can preempt
+   each other, but above that is a strict hierarchy: each can only be
+   preempted by the ones above it.  For example, while a softirq is
+   running on a CPU, no other softirq will preempt it, but a hardware
+   interrupt can.  However, any other CPUs in the system execute
+   independently.
   </para>
 
   <para>
    <title>User Context</title>
 
    <para>
-    User context is when you are coming in from a system call or
-    other trap: you can sleep, and you own the CPU (except for
-    interrupts) until you call <function>schedule()</function>.  
-    In other words, user context (unlike userspace) is not pre-emptable.
+    User context is when you are coming in from a system call or other
+    trap: like userspace, you can be preempted by more important tasks
+    and by interrupts.  You can sleep, by calling
+    <function>schedule()</function>.
    </para>
 
    <note>
 
    <caution>
     <para>
-     Beware that if you have interrupts or bottom halves disabled 
+     Beware that if you have preemption or softirqs disabled
      (see below), <function>in_interrupt()</function> will return a 
      false positive.
     </para>
     <hardware>keyboard</hardware> are examples of real
     hardware which produce interrupts at any time.  The kernel runs
     interrupt handlers, which services the hardware.  The kernel
-    guarantees that this handler is never re-entered: if another
+    guarantees that this handler is never re-entered: if the same
     interrupt arrives, it is queued (or dropped).  Because it
     disables interrupts, this handler has to be fast: frequently it
-    simply acknowledges the interrupt, marks a `software interrupt'
+    simply acknowledges the interrupt, marks a 'software interrupt'
     for execution and exits.
    </para>
 
   </sect1>
 
   <sect1 id="basics-softirqs">
-   <title>Software Interrupt Context: Bottom Halves, Tasklets, softirqs</title>
+   <title>Software Interrupt Context: Softirqs and Tasklets</title>
 
    <para>
     Whenever a system call is about to return to userspace, or a
-    hardware interrupt handler exits, any `software interrupts'
+    hardware interrupt handler exits, any 'software interrupts'
     which are marked pending (usually by hardware interrupts) are
     run (<filename>kernel/softirq.c</filename>).
    </para>
 
    <para>
     Much of the real interrupt handling work is done here.  Early in
-    the transition to <acronym>SMP</acronym>, there were only `bottom 
+    the transition to <acronym>SMP</acronym>, there were only 'bottom
     halves' (BHs), which didn't take advantage of multiple CPUs.  Shortly 
     after we switched from wind-up computers made of match-sticks and snot,
-    we abandoned this limitation.
+    we abandoned this limitation and switched to 'softirqs'.
    </para>
 
    <para>
     <filename class="headerfile">include/linux/interrupt.h</filename> lists the
-    different BH's.  No matter how many CPUs you have, no two BHs will run at 
-    the same time. This made the transition to SMP simpler, but sucks hard for
-    scalable performance.  A very important bottom half is the timer
-    BH (<filename class="headerfile">include/linux/timer.h</filename>): you
-    can register to have it call functions for you in a given length of time.
+    different softirqs.  A very important softirq is the
+    timer softirq (<filename
+    class="headerfile">include/linux/timer.h</filename>): you can
+    register to have it call functions for you in a given length of
+    time.
    </para>
 
    <para>
-    2.3.43 introduced softirqs, and re-implemented the (now
-    deprecated) BHs underneath them.  Softirqs are fully-SMP
-    versions of BHs: they can run on as many CPUs at once as
-    required.  This means they need to deal with any races in shared
-    data using their own locks.  A bitmask is used to keep track of
-    which are enabled, so the 32 available softirqs should not be
-    used up lightly.  (<emphasis>Yes</emphasis>, people will
-    notice).
-   </para>
-
-   <para>
-    tasklets (<filename class="headerfile">include/linux/interrupt.h</filename>)
-    are like softirqs, except they are dynamically-registrable (meaning you 
-    can have as many as you want), and they also guarantee that any tasklet 
-    will only run on one CPU at any time, although different tasklets can 
-    run simultaneously (unlike different BHs).  
+    Softirqs are often a pain to deal with, since the same softirq
+    will run simultaneously on more than one CPU.  For this reason,
+    tasklets (<filename
+    class="headerfile">include/linux/interrupt.h</filename>) are more
+    often used: they are dynamically-registrable (meaning you can have
+    as many as you want), and they also guarantee that any tasklet
+    will only run on one CPU at any time, although different tasklets
+    can run simultaneously.
    </para>
    <caution>
     <para>
-     The name `tasklet' is misleading: they have nothing to do with `tasks', 
+     The name 'tasklet' is misleading: they have nothing to do with 'tasks',
      and probably more to do with some bad vodka Alexey Kuznetsov had at the 
      time.
     </para>
    </caution>
 
    <para>
-    You can tell you are in a softirq (or bottom half, or tasklet)
+    You can tell you are in a softirq (or tasklet)
     using the <function>in_softirq()</function> macro 
     (<filename class="headerfile">include/linux/interrupt.h</filename>).
    </para>
     <term>A rigid stack limit</term>
     <listitem>
      <para>
-      The kernel stack is about 6K in 2.2 (for most
-      architectures: it's about 14K on the Alpha), and shared
-      with interrupts so you can't use it all.  Avoid deep
-      recursion and huge local arrays on the stack (allocate
-      them dynamically instead).
+      Depending on configuration options the kernel stack is about 3K to 6K for most 32-bit architectures: it's
+      about 14K on most 64-bit archs, and often shared with interrupts
+      so you can't use it all.  Avoid deep recursion and huge local
+      arrays on the stack (allocate them dynamically instead).
      </para>
     </listitem>
    </varlistentry>
@@ -339,7 +330,7 @@ asmlinkage long sys_mycall(int arg)
 
   <para>
    If all your routine does is read or write some parameter, consider
-   implementing a <function>sysctl</function> interface instead.
+   implementing a <function>sysfs</function> interface instead.
   </para>
 
   <para>
@@ -417,7 +408,10 @@ cond_resched(); /* Will sleep */
   </para>
 
   <para>
-   You will eventually lock up your box if you break these rules.  
+   You should always compile your kernel
+   <symbol>CONFIG_DEBUG_SPINLOCK_SLEEP</symbol> on, and it will warn
+   you if you break these rules.  If you <emphasis>do</emphasis> break
+   the rules, you will eventually lock up your box.
   </para>
 
   <para>
@@ -515,8 +509,7 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
       success).
      </para>
     </caution>
-    [Yes, this moronic interface makes me cringe.  Please submit a
-    patch and become my hero --RR.]
+    [Yes, this moronic interface makes me cringe.  The flamewar comes up every year or so. --RR.]
    </para>
    <para>
     The functions may sleep implicitly. This should never be called
@@ -587,10 +580,11 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
    </variablelist>
 
    <para>
-    If you see a <errorname>kmem_grow: Called nonatomically from int
-    </errorname> warning message you called a memory allocation function
-    from interrupt context without <constant>GFP_ATOMIC</constant>.
-    You should really fix that.  Run, don't walk.
+    If you see a <errorname>sleeping function called from invalid
+    context</errorname> warning message, then maybe you called a
+    sleeping allocation function from interrupt context without
+    <constant>GFP_ATOMIC</constant>.  You should really fix that.
+    Run, don't walk.
    </para>
 
    <para>
@@ -639,16 +633,16 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
   </sect1>
 
   <sect1 id="routines-udelay">
-   <title><function>udelay()</function>/<function>mdelay()</function>
+   <title><function>mdelay()</function>/<function>udelay()</function>
      <filename class="headerfile">include/asm/delay.h</filename>
      <filename class="headerfile">include/linux/delay.h</filename>
    </title>
 
    <para>
-    The <function>udelay()</function> function can be used for small pauses.
-    Do not use large values with <function>udelay()</function> as you risk
+    The <function>udelay()</function> and <function>ndelay()</function> functions can be used for small pauses.
+    Do not use large values with them as you risk
     overflow - the helper function <function>mdelay()</function> is useful
-    here, or even consider <function>schedule_timeout()</function>.
+    here, or consider <function>msleep()</function>.
    </para> 
   </sect1>
  
@@ -698,8 +692,8 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
     These routines disable soft interrupts on the local CPU, and
     restore them.  They are reentrant; if soft interrupts were
     disabled before, they will still be disabled after this pair
-    of functions has been called.  They prevent softirqs, tasklets
-    and bottom halves from running on the current CPU.
+    of functions has been called.  They prevent softirqs and tasklets
+    from running on the current CPU.
    </para>
   </sect1>
 
@@ -708,10 +702,16 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
     <filename class="headerfile">include/asm/smp.h</filename></title>
    
    <para>
-    <function>smp_processor_id()</function> returns the current
-    processor number, between 0 and <symbol>NR_CPUS</symbol> (the
-    maximum number of CPUs supported by Linux, currently 32).  These
-    values are not necessarily continuous.
+    <function>get_cpu()</function> disables preemption (so you won't
+    suddenly get moved to another CPU) and returns the current
+    processor number, between 0 and <symbol>NR_CPUS</symbol>.  Note
+    that the CPU numbers are not necessarily continuous.  You return
+    it again with <function>put_cpu()</function> when you are done.
+   </para>
+   <para>
+    If you know you cannot be preempted by another task (ie. you are
+    in interrupt context, or have preemption disabled) you can use
+    smp_processor_id().
    </para>
   </sect1>
 
@@ -722,19 +722,14 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
    <para>
     After boot, the kernel frees up a special section; functions
     marked with <type>__init</type> and data structures marked with
-    <type>__initdata</type> are dropped after boot is complete (within
-    modules this directive is currently ignored).  <type>__exit</type>
+    <type>__initdata</type> are dropped after boot is complete: similarly
+    modules discard this memory after initialization.  <type>__exit</type>
     is used to declare a function which is only required on exit: the
     function will be dropped if this file is not compiled as a module.
     See the header file for use. Note that it makes no sense for a function
     marked with <type>__init</type> to be exported to modules with 
     <function>EXPORT_SYMBOL()</function> - this will break.
    </para>
-   <para>
-   Static data structures marked as <type>__initdata</type> must be initialised
-   (as opposed to ordinary static data which is zeroed BSS) and cannot be 
-   <type>const</type>.
-   </para> 
 
   </sect1>
 
@@ -762,9 +757,8 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
    <para>
     The function can return a negative error number to cause
     module loading to fail (unfortunately, this has no effect if
-    the module is compiled into the kernel).  For modules, this is
-    called in user context, with interrupts enabled, and the
-    kernel lock held, so it can sleep.
+    the module is compiled into the kernel).  This function is
+    called in user context with interrupts enabled, so it can sleep.
    </para>
   </sect1>
   
@@ -779,6 +773,34 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
     reached zero.  This function can also sleep, but cannot fail:
     everything must be cleaned up by the time it returns.
    </para>
+
+   <para>
+    Note that this macro is optional: if it is not present, your
+    module will not be removable (except for 'rmmod -f').
+   </para>
+  </sect1>
+
+  <sect1 id="routines-module-use-counters">
+   <title> <function>try_module_get()</function>/<function>module_put()</function>
+    <filename class="headerfile">include/linux/module.h</filename></title>
+
+   <para>
+    These manipulate the module usage count, to protect against
+    removal (a module also can't be removed if another module uses one
+    of its exported symbols: see below).  Before calling into module
+    code, you should call <function>try_module_get()</function> on
+    that module: if it fails, then the module is being removed and you
+    should act as if it wasn't there.  Otherwise, you can safely enter
+    the module, and call <function>module_put()</function> when you're
+    finished.
+   </para>
+
+   <para>
+   Most registerable structures have an
+   <structfield>owner</structfield> field, such as in the
+   <structname>file_operations</structname> structure. Set this field
+   to the macro <symbol>THIS_MODULE</symbol>.
+   </para>
   </sect1>
 
  <!-- add info on new-style module refcounting here -->
@@ -821,7 +843,7 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
     There is a macro to do this:
     <function>wait_event_interruptible()</function>
 
-    <filename class="headerfile">include/linux/sched.h</filename> The
+    <filename class="headerfile">include/linux/wait.h</filename> The
     first argument is the wait queue head, and the second is an
     expression which is evaluated; the macro returns
     <returnvalue>0</returnvalue> when this expression is true, or
@@ -847,10 +869,11 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
    <para>
     Call <function>wake_up()</function>
 
-    <filename class="headerfile">include/linux/sched.h</filename>;,
+    <filename class="headerfile">include/linux/wait.h</filename>;,
     which will wake up every process in the queue.  The exception is
     if one has <constant>TASK_EXCLUSIVE</constant> set, in which case
-    the remainder of the queue will not be woken.
+    the remainder of the queue will not be woken.  There are other variants
+    of this basic function available in the same header.
    </para>
   </sect1>
  </chapter>
@@ -863,7 +886,7 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
    first class of operations work on <type>atomic_t</type>
 
    <filename class="headerfile">include/asm/atomic.h</filename>; this
-   contains a signed integer (at least 24 bits long), and you must use
+   contains a signed integer (at least 32 bits long), and you must use
    these functions to manipulate or read atomic_t variables.
    <function>atomic_read()</function> and
    <function>atomic_set()</function> get and set the counter,
@@ -882,13 +905,12 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
 
   <para>
    Note that these functions are slower than normal arithmetic, and
-   so should not be used unnecessarily.  On some platforms they
-   are much slower, like 32-bit Sparc where they use a spinlock.
+   so should not be used unnecessarily.
   </para>
 
   <para>
-   The second class of atomic operations is atomic bit operations on a
-   <type>long</type>, defined in
+   The second class of atomic operations is atomic bit operations on an
+   <type>unsigned long</type>, defined in
 
    <filename class="headerfile">include/linux/bitops.h</filename>.  These
    operations generally take a pointer to the bit pattern, and a bit
@@ -899,7 +921,7 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
    <function>test_and_clear_bit()</function> and
    <function>test_and_change_bit()</function> do the same thing,
    except return true if the bit was previously set; these are
-   particularly useful for very simple locking.
+   particularly useful for atomically setting flags.
   </para>
   
   <para>
@@ -907,12 +929,6 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
    than BITS_PER_LONG.  The resulting behavior is strange on big-endian
    platforms though so it is a good idea not to do this.
   </para>
-
-  <para>
-   Note that the order of bits depends on the architecture, and in
-   particular, the bitfield passed to these operations must be at
-   least as large as a <type>long</type>.
-  </para>
  </chapter>
 
  <chapter id="symbols">
@@ -932,11 +948,8 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
     <filename class="headerfile">include/linux/module.h</filename></title>
 
    <para>
-    This is the classic method of exporting a symbol, and it works
-    for both modules and non-modules.  In the kernel all these
-    declarations are often bundled into a single file to help
-    genksyms (which searches source files for these declarations).
-    See the comment on genksyms and Makefiles below.
+    This is the classic method of exporting a symbol: dynamically
+    loaded modules will be able to use the symbol as normal.
    </para>
   </sect1>
 
@@ -949,7 +962,8 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
     symbols exported by <function>EXPORT_SYMBOL_GPL()</function> can
     only be seen by modules with a
     <function>MODULE_LICENSE()</function> that specifies a GPL
-    compatible license.
+    compatible license.  It implies that the function is considered
+    an internal implementation issue, and not really an interface.
    </para>
   </sect1>
  </chapter>
@@ -962,12 +976,13 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
     <filename class="headerfile">include/linux/list.h</filename></title>
 
    <para>
-    There are three sets of linked-list routines in the kernel
-    headers, but this one seems to be winning out (and Linus has
-    used it).  If you don't have some particular pressing need for
-    a single list, it's a good choice.  In fact, I don't care
-    whether it's a good choice or not, just use it so we can get
-    rid of the others.
+    There used to be three sets of linked-list routines in the kernel
+    headers, but this one is the winner.  If you don't have some
+    particular pressing need for a single list, it's a good choice.
+   </para>
+
+   <para>
+    In particular, <function>list_for_each_entry</function> is useful.
    </para>
   </sect1>
 
@@ -979,14 +994,13 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
     convention, and return <returnvalue>0</returnvalue> for success,
     and a negative error number
     (eg. <returnvalue>-EFAULT</returnvalue>) for failure.  This can be
-    unintuitive at first, but it's fairly widespread in the networking
-    code, for example.
+    unintuitive at first, but it's fairly widespread in the kernel.
    </para>
 
    <para>
-    The filesystem code uses <function>ERR_PTR()</function>
+    Using <function>ERR_PTR()</function>
 
-    <filename class="headerfile">include/linux/fs.h</filename>; to
+    <filename class="headerfile">include/linux/err.h</filename>; to
     encode a negative error number into a pointer, and
     <function>IS_ERR()</function> and <function>PTR_ERR()</function>
     to get it back out again: avoids a separate pointer parameter for
@@ -1040,7 +1054,7 @@ static struct block_device_operations opt_fops = {
     supported, due to lack of general use, but the following are
     considered standard (see the GCC info page section "C
     Extensions" for more details - Yes, really the info page, the
-    man page is only a short summary of the stuff in info):
+    man page is only a short summary of the stuff in info).
    </para>
    <itemizedlist>
     <listitem>
@@ -1091,7 +1105,7 @@ static struct block_device_operations opt_fops = {
     </listitem>
     <listitem>
      <para>
-      Function names as strings (__FUNCTION__)
+      Function names as strings (__func__).
      </para>
     </listitem>
     <listitem>
@@ -1164,63 +1178,35 @@ static struct block_device_operations opt_fops = {
    <listitem>
     <para>
      Usually you want a configuration option for your kernel hack.
-     Edit <filename>Config.in</filename> in the appropriate directory
-     (but under <filename>arch/</filename> it's called
-     <filename>config.in</filename>).  The Config Language used is not
-     bash, even though it looks like bash; the safe way is to use only
-     the constructs that you already see in
-     <filename>Config.in</filename> files (see
-     <filename>Documentation/kbuild/kconfig-language.txt</filename>).
-     It's good to run "make xconfig" at least once to test (because
-     it's the only one with a static parser).
-    </para>
-
-    <para>
-     Variables which can be Y or N use <type>bool</type> followed by a
-     tagline and the config define name (which must start with
-     CONFIG_).  The <type>tristate</type> function is the same, but
-     allows the answer M (which defines
-     <symbol>CONFIG_foo_MODULE</symbol> in your source, instead of
-     <symbol>CONFIG_FOO</symbol>) if <symbol>CONFIG_MODULES</symbol>
-     is enabled.
+     Edit <filename>Kconfig</filename> in the appropriate directory.
+     The Config language is simple to use by cut and paste, and there's
+     complete documentation in
+     <filename>Documentation/kbuild/kconfig-language.txt</filename>.
     </para>
 
     <para>
      You may well want to make your CONFIG option only visible if
      <symbol>CONFIG_EXPERIMENTAL</symbol> is enabled: this serves as a
      warning to users.  There many other fancy things you can do: see
-     the various <filename>Config.in</filename> files for ideas.
+     the various <filename>Kconfig</filename> files for ideas.
     </para>
-   </listitem>
 
-   <listitem>
     <para>
-     Edit the <filename>Makefile</filename>: the CONFIG variables are
-     exported here so you can conditionalize compilation with `ifeq'.
-     If your file exports symbols then add the names to
-     <varname>export-objs</varname> so that genksyms will find them.
-     <caution>
-      <para>
-       There is a restriction on the kernel build system that objects
-       which export symbols must have globally unique names.
-       If your object does not have a globally unique name then the
-       standard fix is to move the
-       <function>EXPORT_SYMBOL()</function> statements to their own
-       object with a unique name.
-       This is why several systems have separate exporting objects,
-       usually suffixed with ksyms.
-      </para>
-     </caution>
+     In your description of the option, make sure you address both the
+     expert user and the user who knows nothing about your feature.  Mention
+     incompatibilities and issues here.  <emphasis> Definitely
+     </emphasis> end your description with <quote> if in doubt, say N
+     </quote> (or, occasionally, `Y'); this is for people who have no
+     idea what you are talking about.
     </para>
    </listitem>
 
    <listitem>
     <para>
-     Document your option in Documentation/Configure.help.  Mention
-     incompatibilities and issues here.  <emphasis> Definitely
-     </emphasis> end your description with <quote> if in doubt, say N
-     </quote> (or, occasionally, `Y'); this is for people who have no
-     idea what you are talking about.
+     Edit the <filename>Makefile</filename>: the CONFIG variables are
+     exported here so you can usually just add a "obj-$(CONFIG_xxx) +=
+     xxx.o" line.  The syntax is documented in
+     <filename>Documentation/kbuild/makefiles.txt</filename>.
     </para>
    </listitem>
 
@@ -1253,20 +1239,12 @@ static struct block_device_operations opt_fops = {
   </para>
 
   <para>
-   <filename>include/linux/brlock.h:</filename>
+   <filename>include/asm-i386/delay.h:</filename>
   </para>
   <programlisting>
-extern inline void br_read_lock (enum brlock_indices idx)
-{
-        /*
-         * This causes a link-time bug message if an
-         * invalid index is used:
-         */
-        if (idx >= __BR_END)
-                __br_lock_usage_bug();
-
-        read_lock(&amp;__brlock_array[smp_processor_id()][idx]);
-}
+#define ndelay(n) (__builtin_constant_p(n) ? \
+        ((n) > 20000 ? __bad_ndelay() : __const_udelay((n) * 5ul)) : \
+        __ndelay(n))
   </programlisting>
 
   <para>
diff --git a/Documentation/RCU/rcuref.txt b/Documentation/RCU/rcuref.txt
new file mode 100644 (file)
index 0000000..a23fee6
--- /dev/null
@@ -0,0 +1,74 @@
+Refcounter framework for elements of lists/arrays protected by
+RCU.
+
+Refcounting on elements of  lists which are protected by traditional
+reader/writer spinlocks or semaphores are straight forward as in:
+
+1.                                     2.
+add()                                  search_and_reference()
+{                                      {
+       alloc_object                            read_lock(&list_lock);
+       ...                                     search_for_element
+       atomic_set(&el->rc, 1);                 atomic_inc(&el->rc);
+       write_lock(&list_lock);                 ...
+       add_element                             read_unlock(&list_lock);
+       ...                                     ...
+       write_unlock(&list_lock);       }
+}
+
+3.                                     4.
+release_referenced()                   delete()
+{                                      {
+       ...                             write_lock(&list_lock);
+       atomic_dec(&el->rc, relfunc)    ...
+       ...                             delete_element
+}                                      write_unlock(&list_lock);
+                                       ...
+                                       if (atomic_dec_and_test(&el->rc))
+                                               kfree(el);
+                                       ...
+                                       }
+
+If this list/array is made lock free using rcu as in changing the
+write_lock in add() and delete() to spin_lock and changing read_lock
+in search_and_reference to rcu_read_lock(), the rcuref_get in
+search_and_reference could potentially hold reference to an element which
+has already been deleted from the list/array.  rcuref_lf_get_rcu takes
+care of this scenario. search_and_reference should look as;
+
+1.                                     2.
+add()                                  search_and_reference()
+{                                      {
+       alloc_object                            rcu_read_lock();
+       ...                                     search_for_element
+       atomic_set(&el->rc, 1);                 if (rcuref_inc_lf(&el->rc)) {
+       write_lock(&list_lock);                         rcu_read_unlock();
+                                                       return FAIL;
+       add_element                             }
+       ...                                     ...
+       write_unlock(&list_lock);               rcu_read_unlock();
+}                                      }
+3.                                     4.
+release_referenced()                   delete()
+{                                      {
+       ...                             write_lock(&list_lock);
+       rcuref_dec(&el->rc, relfunc)    ...
+       ...                             delete_element
+}                                      write_unlock(&list_lock);
+                                       ...
+                                       if (rcuref_dec_and_test(&el->rc))
+                                               call_rcu(&el->head, el_free);
+                                       ...
+                                       }
+
+Sometimes, reference to the element need to be obtained in the
+update (write) stream.  In such cases, rcuref_inc_lf might be an overkill
+since the spinlock serialising list updates are held. rcuref_inc
+is to be used in such cases.
+For arches which do not have cmpxchg rcuref_inc_lf
+api uses a hashed spinlock implementation and the same hashed spinlock
+is acquired in all rcuref_xxx primitives to preserve atomicity.
+Note: Use rcuref_inc api only if you need to use rcuref_inc_lf on the
+refcounter atleast at one place.  Mixing rcuref_inc and atomic_xxx api
+might lead to races. rcuref_inc_lf() must be used in lockfree
+RCU critical sections only.
diff --git a/Documentation/applying-patches.txt b/Documentation/applying-patches.txt
new file mode 100644 (file)
index 0000000..681e426
--- /dev/null
@@ -0,0 +1,439 @@
+
+       Applying Patches To The Linux Kernel
+       ------------------------------------
+
+       (Written by Jesper Juhl, August 2005)
+
+
+
+A frequently asked question on the Linux Kernel Mailing List is how to apply
+a patch to the kernel or, more specifically, what base kernel a patch for
+one of the many trees/branches should be applied to. Hopefully this document
+will explain this to you.
+
+In addition to explaining how to apply and revert patches, a brief
+description of the different kernel trees (and examples of how to apply
+their specific patches) is also provided.
+
+
+What is a patch?
+---
+ A patch is a small text document containing a delta of changes between two
+different versions of a source tree. Patches are created with the `diff'
+program.
+To correctly apply a patch you need to know what base it was generated from
+and what new version the patch will change the source tree into. These
+should both be present in the patch file metadata or be possible to deduce
+from the filename.
+
+
+How do I apply or revert a patch?
+---
+ You apply a patch with the `patch' program. The patch program reads a diff
+(or patch) file and makes the changes to the source tree described in it.
+
+Patches for the Linux kernel are generated relative to the parent directory
+holding the kernel source dir.
+
+This means that paths to files inside the patch file contain the name of the
+kernel source directories it was generated against (or some other directory
+names like "a/" and "b/").
+Since this is unlikely to match the name of the kernel source dir on your
+local machine (but is often useful info to see what version an otherwise
+unlabeled patch was generated against) you should change into your kernel
+source directory and then strip the first element of the path from filenames
+in the patch file when applying it (the -p1 argument to `patch' does this).
+
+To revert a previously applied patch, use the -R argument to patch.
+So, if you applied a patch like this:
+       patch -p1 < ../patch-x.y.z
+
+You can revert (undo) it like this:
+       patch -R -p1 < ../patch-x.y.z
+
+
+How do I feed a patch/diff file to `patch'?
+---
+ This (as usual with Linux and other UNIX like operating systems) can be
+done in several different ways.
+In all the examples below I feed the file (in uncompressed form) to patch
+via stdin using the following syntax:
+       patch -p1 < path/to/patch-x.y.z
+
+If you just want to be able to follow the examples below and don't want to
+know of more than one way to use patch, then you can stop reading this
+section here.
+
+Patch can also get the name of the file to use via the -i argument, like
+this:
+       patch -p1 -i path/to/patch-x.y.z
+
+If your patch file is compressed with gzip or bzip2 and you don't want to
+uncompress it before applying it, then you can feed it to patch like this
+instead:
+       zcat path/to/patch-x.y.z.gz | patch -p1
+       bzcat path/to/patch-x.y.z.bz2 | patch -p1
+
+If you wish to uncompress the patch file by hand first before applying it
+(what I assume you've done in the examples below), then you simply run
+gunzip or bunzip2 on the file - like this:
+       gunzip patch-x.y.z.gz
+       bunzip2 patch-x.y.z.bz2
+
+Which will leave you with a plain text patch-x.y.z file that you can feed to
+patch via stdin or the -i argument, as you prefer.
+
+A few other nice arguments for patch are -s which causes patch to be silent
+except for errors which is nice to prevent errors from scrolling out of the
+screen too fast, and --dry-run which causes patch to just print a listing of
+what would happen, but doesn't actually make any changes. Finally --verbose
+tells patch to print more information about the work being done.
+
+
+Common errors when patching
+---
+ When patch applies a patch file it attempts to verify the sanity of the
+file in different ways.
+Checking that the file looks like a valid patch file, checking the code
+around the bits being modified matches the context provided in the patch are
+just two of the basic sanity checks patch does.
+
+If patch encounters something that doesn't look quite right it has two
+options. It can either refuse to apply the changes and abort or it can try
+to find a way to make the patch apply with a few minor changes.
+
+One example of something that's not 'quite right' that patch will attempt to
+fix up is if all the context matches, the lines being changed match, but the
+line numbers are different. This can happen, for example, if the patch makes
+a change in the middle of the file but for some reasons a few lines have
+been added or removed near the beginning of the file. In that case
+everything looks good it has just moved up or down a bit, and patch will
+usually adjust the line numbers and apply the patch.
+
+Whenever patch applies a patch that it had to modify a bit to make it fit
+it'll tell you about it by saying the patch applied with 'fuzz'.
+You should be wary of such changes since even though patch probably got it
+right it doesn't /always/ get it right, and the result will sometimes be
+wrong.
+
+When patch encounters a change that it can't fix up with fuzz it rejects it
+outright and leaves a file with a .rej extension (a reject file). You can
+read this file to see exactely what change couldn't be applied, so you can
+go fix it up by hand if you wish.
+
+If you don't have any third party patches applied to your kernel source, but
+only patches from kernel.org and you apply the patches in the correct order,
+and have made no modifications yourself to the source files, then you should
+never see a fuzz or reject message from patch. If you do see such messages
+anyway, then there's a high risk that either your local source tree or the
+patch file is corrupted in some way. In that case you should probably try
+redownloading the patch and if things are still not OK then you'd be advised
+to start with a fresh tree downloaded in full from kernel.org.
+
+Let's look a bit more at some of the messages patch can produce.
+
+If patch stops and presents a "File to patch:" prompt, then patch could not
+find a file to be patched. Most likely you forgot to specify -p1 or you are
+in the wrong directory. Less often, you'll find patches that need to be
+applied with -p0 instead of -p1 (reading the patch file should reveal if
+this is the case - if so, then this is an error by the person who created
+the patch but is not fatal).
+
+If you get "Hunk #2 succeeded at 1887 with fuzz 2 (offset 7 lines)." or a
+message similar to that, then it means that patch had to adjust the location
+of the change (in this example it needed to move 7 lines from where it
+expected to make the change to make it fit).
+The resulting file may or may not be OK, depending on the reason the file
+was different than expected.
+This often happens if you try to apply a patch that was generated against a
+different kernel version than the one you are trying to patch.
+
+If you get a message like "Hunk #3 FAILED at 2387.", then it means that the
+patch could not be applied correctly and the patch program was unable to
+fuzz its way through. This will generate a .rej file with the change that
+caused the patch to fail and also a .orig file showing you the original
+content that couldn't be changed.
+
+If you get "Reversed (or previously applied) patch detected!  Assume -R? [n]"
+then patch detected that the change contained in the patch seems to have
+already been made.
+If you actually did apply this patch previously and you just re-applied it
+in error, then just say [n]o and abort this patch. If you applied this patch
+previously and actually intended to revert it, but forgot to specify -R,
+then you can say [y]es here to make patch revert it for you.
+This can also happen if the creator of the patch reversed the source and
+destination directories when creating the patch, and in that case reverting
+the patch will in fact apply it.
+
+A message similar to "patch: **** unexpected end of file in patch" or "patch
+unexpectedly ends in middle of line" means that patch could make no sense of
+the file you fed to it. Either your download is broken or you tried to feed
+patch a compressed patch file without uncompressing it first.
+
+As I already mentioned above, these errors should never happen if you apply
+a patch from kernel.org to the correct version of an unmodified source tree.
+So if you get these errors with kernel.org patches then you should probably
+assume that either your patch file or your tree is broken and I'd advice you
+to start over with a fresh download of a full kernel tree and the patch you
+wish to apply.
+
+
+Are there any alternatives to `patch'?
+---
+ Yes there are alternatives. You can use the `interdiff' program
+(http://cyberelk.net/tim/patchutils/) to generate a patch representing the
+differences between two patches and then apply the result.
+This will let you move from something like 2.6.12.2 to 2.6.12.3 in a single
+step. The -z flag to interdiff will even let you feed it patches in gzip or
+bzip2 compressed form directly without the use of zcat or bzcat or manual
+decompression.
+
+Here's how you'd go from 2.6.12.2 to 2.6.12.3 in a single step:
+       interdiff -z ../patch-2.6.12.2.bz2 ../patch-2.6.12.3.gz | patch -p1
+
+Although interdiff may save you a step or two you are generally advised to
+do the additional steps since interdiff can get things wrong in some cases.
+
+ Another alternative is `ketchup', which is a python script for automatic
+downloading and applying of patches (http://www.selenic.com/ketchup/).
+
+Other nice tools are diffstat which shows a summary of changes made by a
+patch, lsdiff which displays a short listing of affected files in a patch
+file, along with (optionally) the line numbers of the start of each patch
+and grepdiff which displays a list of the files modified by a patch where
+the patch contains a given regular expression.
+
+
+Where can I download the patches?
+---
+ The patches are available at http://kernel.org/
+Most recent patches are linked from the front page, but they also have
+specific homes.
+
+The 2.6.x.y (-stable) and 2.6.x patches live at
+ ftp://ftp.kernel.org/pub/linux/kernel/v2.6/
+
+The -rc patches live at
+ ftp://ftp.kernel.org/pub/linux/kernel/v2.6/testing/
+
+The -git patches live at
+ ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/
+
+The -mm kernels live at
+ ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/
+
+In place of ftp.kernel.org you can use ftp.cc.kernel.org, where cc is a
+country code. This way you'll be downloading from a mirror site that's most
+likely geographically closer to you, resulting in faster downloads for you,
+less bandwidth used globally and less load on the main kernel.org servers -
+these are good things, do use mirrors when possible.
+
+
+The 2.6.x kernels
+---
+ These are the base stable releases released by Linus. The highest numbered
+release is the most recent.
+
+If regressions or other serious flaws are found then a -stable fix patch
+will be released (see below) on top of this base. Once a new 2.6.x base
+kernel is released, a patch is made available that is a delta between the
+previous 2.6.x kernel and the new one.
+
+To apply a patch moving from 2.6.11 to 2.6.12 you'd do the following (note
+that such patches do *NOT* apply on top of 2.6.x.y kernels but on top of the
+base 2.6.x kernel - if you need to move from 2.6.x.y to 2.6.x+1 you need to
+first revert the 2.6.x.y patch).
+
+Here are some examples:
+
+# moving from 2.6.11 to 2.6.12
+$ cd ~/linux-2.6.11                    # change to kernel source dir
+$ patch -p1 < ../patch-2.6.12          # apply the 2.6.12 patch
+$ cd ..
+$ mv linux-2.6.11 linux-2.6.12         # rename source dir
+
+# moving from 2.6.11.1 to 2.6.12
+$ cd ~/linux-2.6.11.1                  # change to kernel source dir
+$ patch -p1 -R < ../patch-2.6.11.1     # revert the 2.6.11.1 patch
+                                       # source dir is now 2.6.11
+$ patch -p1 < ../patch-2.6.12          # apply new 2.6.12 patch
+$ cd ..
+$ mv linux-2.6.11.1 inux-2.6.12                # rename source dir
+
+
+The 2.6.x.y kernels
+---
+ Kernels with 4 digit versions are -stable kernels. They contain small(ish)
+critical fixes for security problems or significant regressions discovered
+in a given 2.6.x kernel.
+
+This is the recommended branch for users who want the most recent stable
+kernel and are not interested in helping test development/experimental
+versions.
+
+If no 2.6.x.y kernel is available, then the highest numbered 2.6.x kernel is
+the current stable kernel.
+
+These patches are not incremental, meaning that for example the 2.6.12.3
+patch does not apply on top of the 2.6.12.2 kernel source, but rather on top
+of the base 2.6.12 kernel source.
+So, in order to apply the 2.6.12.3 patch to your existing 2.6.12.2 kernel
+source you have to first back out the 2.6.12.2 patch (so you are left with a
+base 2.6.12 kernel source) and then apply the new 2.6.12.3 patch.
+
+Here's a small example:
+
+$ cd ~/linux-2.6.12.2                  # change into the kernel source dir
+$ patch -p1 -R < ../patch-2.6.12.2     # revert the 2.6.12.2 patch
+$ patch -p1 < ../patch-2.6.12.3                # apply the new 2.6.12.3 patch
+$ cd ..
+$ mv linux-2.6.12.2 linux-2.6.12.3     # rename the kernel source dir
+
+
+The -rc kernels
+---
+ These are release-candidate kernels. These are development kernels released
+by Linus whenever he deems the current git (the kernel's source management
+tool) tree to be in a reasonably sane state adequate for testing.
+
+These kernels are not stable and you should expect occasional breakage if
+you intend to run them. This is however the most stable of the main
+development branches and is also what will eventually turn into the next
+stable kernel, so it is important that it be tested by as many people as
+possible.
+
+This is a good branch to run for people who want to help out testing
+development kernels but do not want to run some of the really experimental
+stuff (such people should see the sections about -git and -mm kernels below).
+
+The -rc patches are not incremental, they apply to a base 2.6.x kernel, just
+like the 2.6.x.y patches described above. The kernel version before the -rcN
+suffix denotes the version of the kernel that this -rc kernel will eventually
+turn into.
+So, 2.6.13-rc5 means that this is the fifth release candidate for the 2.6.13
+kernel and the patch should be applied on top of the 2.6.12 kernel source.
+
+Here are 3 examples of how to apply these patches:
+
+# first an example of moving from 2.6.12 to 2.6.13-rc3
+$ cd ~/linux-2.6.12                    # change into the 2.6.12 source dir
+$ patch -p1 < ../patch-2.6.13-rc3      # apply the 2.6.13-rc3 patch
+$ cd ..
+$ mv linux-2.6.12 linux-2.6.13-rc3     # rename the source dir
+
+# now let's move from 2.6.13-rc3 to 2.6.13-rc5
+$ cd ~/linux-2.6.13-rc3                        # change into the 2.6.13-rc3 dir
+$ patch -p1 -R < ../patch-2.6.13-rc3   # revert the 2.6.13-rc3 patch
+$ patch -p1 < ../patch-2.6.13-rc5      # apply the new 2.6.13-rc5 patch
+$ cd ..
+$ mv linux-2.6.13-rc3 linux-2.6.13-rc5 # rename the source dir
+
+# finally let's try and move from 2.6.12.3 to 2.6.13-rc5
+$ cd ~/linux-2.6.12.3                  # change to the kernel source dir
+$ patch -p1 -R < ../patch-2.6.12.3     # revert the 2.6.12.3 patch
+$ patch -p1 < ../patch-2.6.13-rc5      # apply new 2.6.13-rc5 patch
+$ cd ..
+$ mv linux-2.6.12.3 linux-2.6.13-rc5   # rename the kernel source dir
+
+
+The -git kernels
+---
+ These are daily snapshots of Linus' kernel tree (managed in a git
+repository, hence the name).
+
+These patches are usually released daily and represent the current state of
+Linus' tree. They are more experimental than -rc kernels since they are
+generated automatically without even a cursory glance to see if they are
+sane.
+
+-git patches are not incremental and apply either to a base 2.6.x kernel or
+a base 2.6.x-rc kernel - you can see which from their name.
+A patch named 2.6.12-git1 applies to the 2.6.12 kernel source and a patch
+named 2.6.13-rc3-git2 applies to the source of the 2.6.13-rc3 kernel.
+
+Here are some examples of how to apply these patches:
+
+# moving from 2.6.12 to 2.6.12-git1
+$ cd ~/linux-2.6.12                    # change to the kernel source dir
+$ patch -p1 < ../patch-2.6.12-git1     # apply the 2.6.12-git1 patch
+$ cd ..
+$ mv linux-2.6.12 linux-2.6.12-git1    # rename the kernel source dir
+
+# moving from 2.6.12-git1 to 2.6.13-rc2-git3
+$ cd ~/linux-2.6.12-git1               # change to the kernel source dir
+$ patch -p1 -R < ../patch-2.6.12-git1  # revert the 2.6.12-git1 patch
+                                       # we now have a 2.6.12 kernel
+$ patch -p1 < ../patch-2.6.13-rc2      # apply the 2.6.13-rc2 patch
+                                       # the kernel is now 2.6.13-rc2
+$ patch -p1 < ../patch-2.6.13-rc2-git3 # apply the 2.6.13-rc2-git3 patch
+                                       # the kernel is now 2.6.13-rc2-git3
+$ cd ..
+$ mv linux-2.6.12-git1 linux-2.6.13-rc2-git3   # rename source dir
+
+
+The -mm kernels
+---
+ These are experimental kernels released by Andrew Morton.
+
+The -mm tree serves as a sort of proving ground for new features and other
+experimental patches.
+Once a patch has proved its worth in -mm for a while Andrew pushes it on to
+Linus for inclusion in mainline.
+
+Although it's encouraged that patches flow to Linus via the -mm tree, this
+is not always enforced.
+Subsystem maintainers (or individuals) sometimes push their patches directly
+to Linus, even though (or after) they have been merged and tested in -mm (or
+sometimes even without prior testing in -mm).
+
+You should generally strive to get your patches into mainline via -mm to
+ensure maximum testing.
+
+This branch is in constant flux and contains many experimental features, a
+lot of debugging patches not appropriate for mainline etc and is the most
+experimental of the branches described in this document.
+
+These kernels are not appropriate for use on systems that are supposed to be
+stable and they are more risky to run than any of the other branches (make
+sure you have up-to-date backups - that goes for any experimental kernel but
+even more so for -mm kernels).
+
+These kernels in addition to all the other experimental patches they contain
+usually also contain any changes in the mainline -git kernels available at
+the time of release.
+
+Testing of -mm kernels is greatly appreciated since the whole point of the
+tree is to weed out regressions, crashes, data corruption bugs, build
+breakage (and any other bug in general) before changes are merged into the
+more stable mainline Linus tree.
+But testers of -mm should be aware that breakage in this tree is more common
+than in any other tree.
+
+The -mm kernels are not released on a fixed schedule, but usually a few -mm
+kernels are released in between each -rc kernel (1 to 3 is common).
+The -mm kernels apply to either a base 2.6.x kernel (when no -rc kernels
+have been released yet) or to a Linus -rc kernel.
+
+Here are some examples of applying the -mm patches:
+
+# moving from 2.6.12 to 2.6.12-mm1
+$ cd ~/linux-2.6.12                    # change to the 2.6.12 source dir
+$ patch -p1 < ../2.6.12-mm1            # apply the 2.6.12-mm1 patch
+$ cd ..
+$ mv linux-2.6.12 linux-2.6.12-mm1     # rename the source appropriately
+
+# moving from 2.6.12-mm1 to 2.6.13-rc3-mm3
+$ cd ~/linux-2.6.12-mm1
+$ patch -p1 -R < ../2.6.12-mm1         # revert the 2.6.12-mm1 patch
+                                       # we now have a 2.6.12 source
+$ patch -p1 < ../patch-2.6.13-rc3      # apply the 2.6.13-rc3 patch
+                                       # we now have a 2.6.13-rc3 source
+$ patch -p1 < ../2.6.13-rc3-mm3                # apply the 2.6.13-rc3-mm3 patch
+$ cd ..
+$ mv linux-2.6.12-mm1 linux-2.6.13-rc3-mm3     # rename the source dir
+
+
+This concludes this list of explanations of the various kernel trees and I
+hope you are now crystal clear on how to apply the various patches and help
+testing the kernel.
+
index 4b8c326c6aac91fcd0d04db82b12114850376c52..cb63b7a93c82f02e47c79076bbf2723f0bec77d2 100644 (file)
@@ -1,55 +1,74 @@
-How to get the Nebula Electronics DigiTV, Pinnacle PCTV Sat, Twinhan DST + clones working
-=========================================================================================
+How to get the Nebula, PCTV and Twinhan DST cards working
+=========================================================
 
-1) General information
-======================
+This class of cards has a bt878a as the PCI interface, and
+require the bttv driver.
 
-This class of cards has a bt878a chip as the PCI interface.
-The different card drivers require the bttv driver to provide the means
-to access the i2c bus and the gpio pins of the bt8xx chipset.
+Please pay close attention to the warning about the bttv module
+options below for the DST card.
 
-2) Compilation rules for Kernel >= 2.6.12
-=========================================
+1) General informations
+=======================
 
-Enable the following options:
+These drivers require the bttv driver to provide the means to access
+the i2c bus and the gpio pins of the bt8xx chipset.
 
+Because of this, you need to enable
 "Device drivers" => "Multimedia devices"
- => "Video For Linux" => "BT848 Video For Linux"
+  => "Video For Linux" => "BT848 Video For Linux"
+
+Furthermore you need to enable
 "Device drivers" => "Multimedia devices" => "Digital Video Broadcasting Devices"
- => "DVB for Linux" "DVB Core Support" "BT8xx based PCI cards"
 => "DVB for Linux" "DVB Core Support" "BT8xx based PCI cards"
 
-3) Loading Modules, described by two approaches
-===============================================
+2) Loading Modules
+==================
 
 In general you need to load the bttv driver, which will handle the gpio and
-i2c communication for us, plus the common dvb-bt8xx device driver,
-which is called the backend.
-The frontends for Nebula DigiTV (nxt6000), Pinnacle PCTV Sat (cx24110),
-TwinHan DST + clones (dst and dst-ca) are loaded automatically by the backend.
-For further details about TwinHan DST + clones see /Documentation/dvb/ci.txt.
+i2c communication for us, plus the common dvb-bt8xx device driver.
+The frontends for Nebula (nxt6000), Pinnacle PCTV (cx24110) and
+TwinHan (dst) are loaded automatically by the dvb-bt8xx device driver.
 
-3a) The manual approach
------------------------
+3a) Nebula / Pinnacle PCTV
+--------------------------
 
-Loading modules:
-modprobe bttv
-modprobe dvb-bt8xx
+   $ modprobe bttv (normally bttv is being loaded automatically by kmod)
+   $ modprobe dvb-bt8xx (or just place dvb-bt8xx in /etc/modules for automatic loading)
 
-Unloading modules:
-modprobe -r dvb-bt8xx
-modprobe -r bttv
 
-3b) The automatic approach
+3b) TwinHan and Clones
 --------------------------
 
-If not already done by installation, place a line either in
-/etc/modules.conf or in /etc/modprobe.conf containing this text:
-alias char-major-81    bttv
+   $ modprobe bttv i2c_hw=1 card=0x71
+   $ modprobe dvb-bt8xx
+   $ modprobe dst
+
+The value 0x71 will override the PCI type detection for dvb-bt8xx,
+which  is necessary for TwinHan cards.
+
+If you're having an older card (blue color circuit) and card=0x71 locks
+your machine, try using 0x68, too. If that does not work, ask on the
+mailing list.
+
+The DST module takes a couple of useful parameters.
+
+verbose takes values 0 to 4. These values control the verbosity level,
+and can be used to debug also.
+
+verbose=0 means complete disabling of messages
+       1 only error messages are displayed
+       2 notifications are also displayed
+       3 informational messages are also displayed
+       4 debug setting
+
+dst_addons takes values 0 and 0x20. A value of 0 means it is a FTA card.
+0x20 means it has a Conditional Access slot.
+
+The autodected values are determined bythe cards 'response
+string' which you can see in your logs e.g.
 
-Then place a line in /etc/modules containing this text:
-dvb-bt8xx
+dst_get_device_id: Recognise [DSTMCI]
 
-Reboot your system and have fun!
 
 --
-Authors: Richard Walker, Jamie Honan, Michael Hunold, Manu Abraham, Uwe Bugla
+Authors: Richard Walker, Jamie Honan, Michael Hunold, Manu Abraham
index 62e0701b542af416092a6a4aa8cafe6f1b04f008..95f0e73b2135a10463476e0fbe789dba62eb2ef5 100644 (file)
@@ -23,7 +23,6 @@ This application requires the following to function properly as of now.
          eg: $ szap -c channels.conf -r "TMC" -x
 
        (b) a channels.conf containing a valid PMT PID
-
          eg: TMC:11996:h:0:27500:278:512:650:321
 
          here 278 is a valid PMT PID. the rest of the values are the
@@ -31,13 +30,7 @@ This application requires the following to function properly as of now.
 
        (c) after running a szap, you have to run ca_zap, for the
          descrambler to function,
-
-         eg: $ ca_zap patched_channels.conf "TMC"
-
-         The patched means a patch to apply to scan, such that scan can
-         generate a channels.conf_with pmt, which has this PMT PID info
-         (NOTE: szap cannot use this channels.conf with the PMT_PID)
-
+         eg: $ ca_zap channels.conf "TMC"
 
        (d) Hopeflly Enjoy your favourite subscribed channel as you do with
          a FTA card.
diff --git a/Documentation/fb/cyblafb/bugs b/Documentation/fb/cyblafb/bugs
new file mode 100644 (file)
index 0000000..f90cc66
--- /dev/null
@@ -0,0 +1,14 @@
+Bugs
+====
+
+I currently don't know of any bug. Please do send reports to:
+ - linux-fbdev-devel@lists.sourceforge.net
+ - Knut_Petersen@t-online.de.
+
+
+Untested features
+=================
+
+All LCD stuff is untested. If it worked in tridentfb, it should work in
+cyblafb. Please test and report the results to Knut_Petersen@t-online.de.
+
diff --git a/Documentation/fb/cyblafb/credits b/Documentation/fb/cyblafb/credits
new file mode 100644 (file)
index 0000000..0eb3b44
--- /dev/null
@@ -0,0 +1,7 @@
+Thanks to
+=========
+   *   Alan Hourihane, for writing the X trident driver
+   *   Jani Monoses, for writing the tridentfb driver
+   *   Antonino A. Daplas, for review of the first published
+       version of cyblafb and some code
+   *   Jochen Hein, for testing and a helpfull bug report
diff --git a/Documentation/fb/cyblafb/documentation b/Documentation/fb/cyblafb/documentation
new file mode 100644 (file)
index 0000000..bb1aac0
--- /dev/null
@@ -0,0 +1,17 @@
+Available Documentation
+=======================
+
+Apollo PLE 133 Chipset VT8601A North Bridge Datasheet, Rev. 1.82, October 22,
+2001, available from VIA:
+
+       http://www.viavpsd.com/product/6/15/DS8601A182.pdf
+
+The datasheet is incomplete, some registers that need to be programmed are not
+explained at all and important bits are listed as "reserved". But you really
+need the datasheet to understand the code.  "p. xxx" comments refer to page
+numbers of this document.
+
+XFree/XOrg drivers are available and of good quality, looking at the code
+there is a good idea if the datasheet does not provide enough information
+or if the datasheet seems to be wrong.
+
diff --git a/Documentation/fb/cyblafb/fb.modes b/Documentation/fb/cyblafb/fb.modes
new file mode 100644 (file)
index 0000000..cf4351f
--- /dev/null
@@ -0,0 +1,155 @@
+#
+#   Sample fb.modes file
+#
+#      Provides an incomplete list of working modes for
+#      the cyberblade/i1 graphics core.
+#
+#      The value 4294967256 is used instead of -40. Of course, -40 is not
+#      a really reasonable value, but chip design does not always follow
+#      logic. Believe me, it's ok, and it's the way the BIOS does it.
+#
+#      fbset requires 4294967256 in fb.modes and -40 as an argument to
+#      the -t parameter. That's also not too reasonable, and it might change
+#      in the future or might even be differt for your current version.
+#
+
+mode "640x480-50"
+    geometry 640 480 640 3756 8
+    timings 47619 4294967256 24 17 0 216 3
+endmode
+
+mode "640x480-60"
+    geometry 640 480 640 3756 8
+    timings 39682 4294967256 24 17 0 216 3
+endmode
+
+mode "640x480-70"
+    geometry 640 480 640 3756 8
+    timings 34013 4294967256 24 17 0 216 3
+endmode
+
+mode "640x480-72"
+    geometry 640 480 640 3756 8
+    timings 33068 4294967256 24 17 0 216 3
+endmode
+
+mode "640x480-75"
+    geometry 640 480 640 3756 8
+    timings 31746 4294967256 24 17 0 216 3
+endmode
+
+mode "640x480-80"
+    geometry 640 480 640 3756 8
+    timings 29761 4294967256 24 17 0 216 3
+endmode
+
+mode "640x480-85"
+    geometry 640 480 640 3756 8
+    timings 28011 4294967256 24 17 0 216 3
+endmode
+
+mode "800x600-50"
+    geometry 800 600 800 3221 8
+    timings 30303 96 24 14 0 136 11
+endmode
+
+mode "800x600-60"
+    geometry 800 600 800 3221 8
+    timings 25252 96 24 14 0 136 11
+endmode
+
+mode "800x600-70"
+    geometry 800 600 800 3221 8
+    timings 21645 96 24 14 0 136 11
+endmode
+
+mode "800x600-72"
+    geometry 800 600 800 3221 8
+    timings 21043 96 24 14 0 136 11
+endmode
+
+mode "800x600-75"
+    geometry 800 600 800 3221 8
+    timings 20202 96 24 14 0 136 11
+endmode
+
+mode "800x600-80"
+    geometry 800 600 800 3221 8
+    timings 18939 96 24 14 0 136 11
+endmode
+
+mode "800x600-85"
+    geometry 800 600 800 3221 8
+    timings 17825 96 24 14 0 136 11
+endmode
+
+mode "1024x768-50"
+    geometry 1024 768 1024 2815 8
+    timings 19054 144 24 29 0 120 3
+endmode
+
+mode "1024x768-60"
+    geometry 1024 768 1024 2815 8
+    timings 15880 144 24 29 0 120 3
+endmode
+
+mode "1024x768-70"
+    geometry 1024 768 1024 2815 8
+    timings 13610 144 24 29 0 120 3
+endmode
+
+mode "1024x768-72"
+    geometry 1024 768 1024 2815 8
+    timings 13232 144 24 29 0 120 3
+endmode
+
+mode "1024x768-75"
+    geometry 1024 768 1024 2815 8
+    timings 12703 144 24 29 0 120 3
+endmode
+
+mode "1024x768-80"
+    geometry 1024 768 1024 2815 8
+    timings 11910 144 24 29 0 120 3
+endmode
+
+mode "1024x768-85"
+    geometry 1024 768 1024 2815 8
+    timings 11209 144 24 29 0 120 3
+endmode
+
+mode "1280x1024-50"
+    geometry 1280 1024 1280 2662 8
+    timings 11114 232 16 39 0 160 3
+endmode
+
+mode "1280x1024-60"
+    geometry 1280 1024 1280 2662 8
+    timings 9262 232 16 39 0 160 3
+endmode
+
+mode "1280x1024-70"
+    geometry 1280 1024 1280 2662 8
+    timings 7939 232 16 39 0 160 3
+endmode
+
+mode "1280x1024-72"
+    geometry 1280 1024 1280 2662 8
+    timings 7719 232 16 39 0 160 3
+endmode
+
+mode "1280x1024-75"
+    geometry 1280 1024 1280 2662 8
+    timings 7410 232 16 39 0 160 3
+endmode
+
+mode "1280x1024-80"
+    geometry 1280 1024 1280 2662 8
+    timings 6946 232 16 39 0 160 3
+endmode
+
+mode "1280x1024-85"
+    geometry 1280 1024 1280 2662 8
+    timings 6538 232 16 39 0 160 3
+endmode
+
diff --git a/Documentation/fb/cyblafb/performance b/Documentation/fb/cyblafb/performance
new file mode 100644 (file)
index 0000000..eb4e47a
--- /dev/null
@@ -0,0 +1,80 @@
+Speed
+=====
+
+CyBlaFB is much faster than tridentfb and vesafb. Compare the performance data
+for mode 1280x1024-[8,16,32]@61 Hz.
+
+Test 1: Cat a file with 2000 lines of 0 characters.
+Test 2: Cat a file with 2000 lines of 80 characters.
+Test 3: Cat a file with 2000 lines of 160 characters.
+
+All values show system time use in seconds, kernel 2.6.12 was used for
+the measurements. 2.6.13 is a bit slower, 2.6.14 hopefully will include a
+patch that speeds up kernel bitblitting a lot ( > 20%).
+
++-----------+-----------------------------------------------------+
+|          |                   not accelerated                   |
+| TRIDENTFB +-----------------+-----------------+-----------------+
+| of 2.6.12 |     8 bpp      |     16 bpp      |     32 bpp      |
+|          | noypan |   ypan | noypan |   ypan | noypan |   ypan |
++-----------+--------+--------+--------+--------+--------+--------+
+|    Test 1 |  4.31 |   4.33 |   6.05 |  12.81 |  ----  |  ----  |
+|    Test 2 |  67.94 |  5.44 | 123.16 |  14.79 |  ----  |  ----  |
+|    Test 3 | 131.36 |  6.55 | 240.12 |  16.76 |  ----  |  ----  |
++-----------+--------+--------+--------+--------+--------+--------+
+|  Comments |                |                 | completely bro- |
+|          |                 |                 | ken, monitor    |
+|          |                 |                 | switches off    |
++-----------+-----------------+-----------------+-----------------+
+
+
++-----------+-----------------------------------------------------+
+|          |                     accelerated                     |
+| TRIDENTFB +-----------------+-----------------+-----------------+
+| of 2.6.12 |     8 bpp      |     16 bpp      |     32 bpp      |
+|          | noypan |   ypan | noypan |   ypan | noypan |   ypan |
++-----------+--------+--------+--------+--------+--------+--------+
+|    Test 1 |  ----  | ----  |  20.62 |   1.22 |  ----  |  ----  |
+|    Test 2 |  ----  | ----  |  22.61 |   3.19 |  ----  |  ----  |
+|    Test 3 |  ----  | ----  |  24.59 |   5.16 |  ----  |  ----  |
++-----------+--------+--------+--------+--------+--------+--------+
+|  Comments | broken, writing | broken, ok only | completely bro- |
+|          | to wrong places | if bgcolor is   | ken, monitor    |
+|          | on screen + bug | black, bug in   | switches off    |
+|          | in fillrect()   | fillrect()      |                 |
++-----------+-----------------+-----------------+-----------------+
+
+
++-----------+-----------------------------------------------------+
+|          |                   not accelerated                   |
+|   VESAFB  +-----------------+-----------------+-----------------+
+| of 2.6.12 |     8 bpp      |     16 bpp      |     32 bpp      |
+|          | noypan |   ypan | noypan |   ypan | noypan |   ypan |
++-----------+--------+--------+--------+--------+--------+--------+
+|    Test 1 |  4.26 |   3.76 |   5.99 |   7.23 |  ----  |  ----  |
+|    Test 2 |  65.65 |  4.89 | 120.88 |   9.08 |  ----  |  ----  |
+|    Test 3 | 126.91 |  5.94 | 235.77 |  11.03 |  ----  |  ----  |
++-----------+--------+--------+--------+--------+--------+--------+
+|  Comments | vga=0x307       | vga=0x31a      | vga=0x31b not   |
+|          | fh=80kHz        | fh=80kHz        | supported by    |
+|          | fv=75kHz        | fv=75kHz        | video BIOS and  |
+|          |                 |                 | hardware        |
++-----------+-----------------+-----------------+-----------------+
+
+
++-----------+-----------------------------------------------------+
+|          |                     accelerated                     |
+|  CYBLAFB  +-----------------+-----------------+-----------------+
+|          |      8 bpp      |     16 bpp      |     32 bpp      |
+|          | noypan |   ypan | noypan |   ypan | noypan |   ypan |
++-----------+--------+--------+--------+--------+--------+--------+
+|    Test 1 |  8.02 |   0.23 |  19.04 |   0.61 |  57.12 |   2.74 |
+|    Test 2 |  8.38 |   0.55 |  19.39 |   0.92 |  57.54 |   3.13 |
+|    Test 3 |  8.73 |   0.86 |  19.74 |   1.24 |  57.95 |   3.51 |
++-----------+--------+--------+--------+--------+--------+--------+
+|  Comments |                |                 |                 |
+|          |                 |                 |                 |
+|          |                 |                 |                 |
+|          |                 |                 |                 |
++-----------+-----------------+-----------------+-----------------+
+
diff --git a/Documentation/fb/cyblafb/todo b/Documentation/fb/cyblafb/todo
new file mode 100644 (file)
index 0000000..80fb2f8
--- /dev/null
@@ -0,0 +1,32 @@
+TODO / Missing features
+=======================
+
+Verify LCD stuff               "stretch" and "center" options are
+                               completely untested ... this code needs to be
+                               verified. As I don't have access to such
+                               hardware, please contact me if you are
+                               willing run some tests.
+
+Interlaced video modes         The reason that interleaved
+                               modes are disabled is that I do not know
+                               the meaning of the vertical interlace
+                               parameter. Also the datasheet mentions a
+                               bit d8 of a horizontal interlace parameter,
+                               but nowhere the lower 8 bits. Please help
+                               if you can.
+
+low-res double scan modes      Who needs it?
+
+accelerated color blitting     Who needs it? The console driver does use color
+                               blitting for nothing but drawing the penguine,
+                               everything else is done using color expanding
+                               blitting of 1bpp character bitmaps.
+
+xpanning                       Who needs it?
+
+ioctls                         Who needs it?
+
+TV-out                         Will be done later
+
+???                            Feel free to contact me if you have any
+                               feature requests
diff --git a/Documentation/fb/cyblafb/usage b/Documentation/fb/cyblafb/usage
new file mode 100644 (file)
index 0000000..e627c8f
--- /dev/null
@@ -0,0 +1,206 @@
+CyBlaFB is a framebuffer driver for the Cyberblade/i1 graphics core integrated
+into the VIA Apollo PLE133 (aka vt8601) south bridge. It is developed and
+tested using a VIA EPIA 5000 board.
+
+Cyblafb - compiled into the kernel or as a module?
+==================================================
+
+You might compile cyblafb either as a module or compile it permanently into the
+kernel.
+
+Unless you have a real reason to do so you should not compile both vesafb and
+cyblafb permanently into the kernel. It's possible and it helps during the
+developement cycle, but it's useless and will at least block some otherwise
+usefull memory for ordinary users.
+
+Selecting Modes
+===============
+
+       Startup Mode
+       ============
+
+       First of all, you might use the "vga=???" boot parameter as it is
+       documented in vesafb.txt and svga.txt. Cyblafb will detect the video
+       mode selected and will use the geometry and timings found by
+       inspecting the hardware registers.
+
+               video=cyblafb vga=0x317
+
+       Alternatively you might use a combination of the mode, ref and bpp
+       parameters. If you compiled the driver into the kernel, add something
+       like this to the kernel command line:
+
+               video=cyblafb:1280x1024,bpp=16,ref=50 ...
+
+       If you compiled the driver as a module, the same mode would be
+       selected by the following command:
+
+               modprobe cyblafb mode=1280x1024 bpp=16 ref=50 ...
+
+       None of the modes possible to select as startup modes are affected by
+       the problems described at the end of the next subsection.
+
+       Mode changes using fbset
+       ========================
+
+       You might use fbset to change the video mode, see "man fbset". Cyblafb
+       generally does assume that you know what you are doing. But it does
+       some checks, especially those that are needed to prevent you from
+       damaging your hardware.
+
+               - only 8, 16, 24 and 32 bpp video modes are accepted
+               - interlaced video modes are not accepted
+               - double scan video modes are not accepted
+               - if a flat panel is found, cyblafb does not allow you
+                 to program a resolution higher than the physical
+                 resolution of the flat panel monitor
+               - cyblafb does not allow xres to differ from xres_virtual
+               - cyblafb does not allow vclk to exceed 230 MHz. As 32 bpp
+                 and (currently) 24 bit modes use a doubled vclk internally,
+                 the dotclock limit as seen by fbset is 115 MHz for those
+                 modes and 230 MHz for 8 and 16 bpp modes.
+
+       Any request that violates the rules given above will be ignored and
+       fbset will return an error.
+
+       If you program a virtual y resolution higher than the hardware limit,
+       cyblafb will silently decrease that value to the highest possible
+       value.
+
+       Attempts to disable acceleration are ignored.
+
+       Some video modes that should work do not work as expected. If you use
+       the standard fb.modes, fbset 640x480-60 will program that mode, but
+       you will see a vertical area, about two characters wide, with only
+       much darker characters than the other characters on the screen.
+       Cyblafb does allow that mode to be set, as it does not violate the
+       official specifications. It would need a lot of code to reliably sort
+       out all invalid modes, playing around with the margin values will
+       give a valid mode quickly. And if cyblafb would detect such an invalid
+       mode, should it silently alter the requested values or should it
+       report an error? Both options have some pros and cons. As stated
+       above, none of the startup modes are affected, and if you set
+       verbosity to 1 or higher, cyblafb will print the fbset command that
+       would be needed to program that mode using fbset.
+
+
+Other Parameters
+================
+
+
+crt            don't autodetect, assume monitor connected to
+               standard VGA connector
+
+fp             don't autodetect, assume flat panel display
+               connected to flat panel monitor interface
+
+nativex        inform driver about native x resolution of
+               flat panel monitor connected to special
+               interface (should be autodetected)
+
+stretch        stretch image to adapt low resolution modes to
+               higer resolutions of flat panel monitors
+               connected to special interface
+
+center         center image to adapt low resolution modes to
+               higer resolutions of flat panel monitors
+               connected to special interface
+
+memsize        use if autodetected memsize is wrong ...
+               should never be necessary
+
+nopcirr        disable PCI read retry
+nopciwr        disable PCI write retry
+nopcirb        disable PCI read bursts
+nopciwb        disable PCI write bursts
+
+bpp            bpp for specified modes
+               valid values: 8 || 16 || 24 || 32
+
+ref            refresh rate for specified mode
+               valid values: 50 <= ref <= 85
+
+mode           640x480 or 800x600 or 1024x768 or 1280x1024
+               if not specified, the startup mode will be detected
+               and used, so you might also use the vga=??? parameter
+               described in vesafb.txt. If you do not specify a mode,
+               bpp and ref parameters are ignored.
+
+verbosity      0 is the default, increase to at least 2 for every
+               bug report!
+
+vesafb         allows cyblafb to be loaded after vesafb has been
+               loaded. See sections "Module unloading ...".
+
+
+Development hints
+=================
+
+It's much faster do compile a module and to load the new version after
+unloading the old module than to compile a new kernel and to reboot. So if you
+try to work on cyblafb, it might be a good idea to use cyblafb as a module.
+In real life, fast often means dangerous, and that's also the case here. If
+you introduce a serious bug when cyblafb is compiled into the kernel, the
+kernel will lock or oops with a high probability before the file system is
+mounted, and the danger for your data is low. If you load a broken own version
+of cyblafb on a running system, the danger for the integrity of the file
+system is much higher as you might need a hard reset afterwards. Decide
+yourself.
+
+Module unloading, the vfb method
+================================
+
+If you want to unload/reload cyblafb using the virtual framebuffer, you need
+to enable vfb support in the kernel first. After that, load the modules as
+shown below:
+
+       modprobe vfb vfb_enable=1
+       modprobe fbcon
+       modprobe cyblafb
+       fbset -fb /dev/fb1 1280x1024-60 -vyres 2662
+       con2fb /dev/fb1 /dev/tty1
+       ...
+
+If you now made some changes to cyblafb and want to reload it, you might do it
+as show below:
+
+       con2fb /dev/fb0 /dev/tty1
+       ...
+       rmmod cyblafb
+       modprobe cyblafb
+       con2fb /dev/fb1 /dev/tty1
+       ...
+
+Of course, you might choose another mode, and most certainly you also want to
+map some other /dev/tty* to the real framebuffer device. You might also choose
+to compile fbcon as a kernel module or place it permanently in the kernel.
+
+I do not know of any way to unload fbcon, and fbcon will prevent the
+framebuffer device loaded first from unloading. [If there is a way, then
+please add a description here!]
+
+Module unloading, the vesafb method
+===================================
+
+Configure the kernel:
+
+       <*> Support for frame buffer devices
+       [*]   VESA VGA graphics support
+       <M>   Cyberblade/i1 support
+
+Add e.g. "video=vesafb:ypan vga=0x307" to the kernel parameters. The ypan
+parameter is important, choose any vga parameter you like as long as it is
+a graphics mode.
+
+After booting, load cyblafb without any mode and bpp parameter and assign
+cyblafb to individual ttys using con2fb, e.g.:
+
+       modprobe cyblafb vesafb=1
+       con2fb /dev/fb1 /dev/tty1
+
+Unloading cyblafb works without problems after you assign vesafb to all
+ttys again, e.g.:
+
+       con2fb /dev/fb0 /dev/tty1
+       rmmod cyblafb
+
diff --git a/Documentation/fb/cyblafb/whycyblafb b/Documentation/fb/cyblafb/whycyblafb
new file mode 100644 (file)
index 0000000..a123bc1
--- /dev/null
@@ -0,0 +1,85 @@
+I tried the following framebuffer drivers:
+
+       - TRIDENTFB is full of bugs. Acceleration is broken for Blade3D
+         graphics cores like the cyberblade/i1. It claims to support a great
+         number of devices, but documentation for most of these devices is
+         unfortunately not available. There is _no_ reason to use tridentfb
+         for cyberblade/i1 + CRT users. VESAFB is faster, and the one
+         advantage, mode switching, is broken in tridentfb.
+
+       - VESAFB is used by many distributions as a standard. Vesafb does
+         not support mode switching. VESAFB is a bit faster than the working
+         configurations of TRIDENTFB, but it is still too slow, even if you
+         use ypan.
+
+       - EPIAFB (you'll find it on sourceforge) supports the Cyberblade/i1
+         graphics core, but it still has serious bugs and developement seems
+         to have stopped. This is the one driver with TV-out support. If you
+         do need this feature, try epiafb.
+
+None of these drivers was a real option for me.
+
+I believe that is unreasonable to change code that announces to support 20
+devices if I only have more or less sufficient documentation for exactly one
+of these. The risk of breaking device foo while fixing device bar is too high.
+
+So I decided to start CyBlaFB as a stripped down tridentfb.
+
+All code specific to other Trident chips has been removed. After that there
+were a lot of cosmetic changes to increase the readability of the code. All
+register names were changed to those mnemonics used in the datasheet. Function
+and macro names were changed if they hindered easy understanding of the code.
+
+After that I debugged the code and implemented some new features. I'll try to
+give a little summary of the main changes:
+
+       - calculation of vertical and horizontal timings was fixed
+
+       - video signal quality has been improved dramatically
+
+       - acceleration:
+
+               - fillrect and copyarea were fixed and reenabled
+
+               - color expanding imageblit was newly implemented, color
+                 imageblit (only used to draw the penguine) still uses the
+                 generic code.
+
+               - init of the acceleration engine was improved and moved to a
+                 place where it really works ...
+
+               - sync function has a timeout now and tries to reset and
+                 reinit the accel engine if necessary
+
+               - fewer slow copyarea calls when doing ypan scrolling by using
+                 undocumented bit d21 of screen start address stored in
+                 CR2B[5]. BIOS does use it also, so this should be safe.
+
+       - cyblafb rejects any attempt to set modes that would cause vclk
+         values above reasonable 230 MHz. 32bit modes use a clock
+         multiplicator of 2, so fbset does show the correct values for
+         pixclock but not for vclk in this case. The fbset limit is 115 MHz
+         for 32 bpp modes.
+
+       - cyblafb rejects modes known to be broken or unimplemented (all
+         interlaced modes, all doublescan modes for now)
+
+       - cyblafb now works independant of the video mode in effect at startup
+         time (tridentfb does not init all needed registers to reasonable
+         values)
+
+       - switching between video modes does work reliably now
+
+       - the first video mode now is the one selected on startup using the
+         vga=???? mechanism or any of
+               - 640x480, 800x600, 1024x768, 1280x1024
+               - 8, 16, 24 or 32 bpp
+               - refresh between 50 Hz and 85 Hz, 1 Hz steps (1280x1024-32
+                 is limited to 63Hz)
+
+       - pci retry and pci burst mode are settable (try to disable if you
+         experience latency problems)
+
+       - built as a module cyblafb might be unloaded and reloaded using
+         the vfb module and con2vt or might be used together with vesafb
+
index e04458b319d576ac076a0e09211108a8b4390f7b..4fcdb4cf4cca922c91d7ff699154c5ecae39778d 100644 (file)
@@ -20,12 +20,83 @@ in a video= option, fbmem considers that to be a global video mode option.
 
 Valid mode specifiers (mode_option argument):
 
-    <xres>x<yres>[-<bpp>][@<refresh>]
+    <xres>x<yres>[M][R][-<bpp>][@<refresh>][i][m]
     <name>[-<bpp>][@<refresh>]
 
 with <xres>, <yres>, <bpp> and <refresh> decimal numbers and <name> a string.
 Things between square brackets are optional.
 
+If 'M' is specified in the mode_option argument (after <yres> and before
+<bpp> and <refresh>, if specified) the timings will be calculated using
+VESA(TM) Coordinated Video Timings instead of looking up the mode from a table.
+If 'R' is specified, do a 'reduced blanking' calculation for digital displays.
+If 'i' is specified, calculate for an interlaced mode.  And if 'm' is
+specified, add margins to the calculation (1.8% of xres rounded down to 8
+pixels and 1.8% of yres).
+
+       Sample usage: 1024x768M@60m - CVT timing with margins
+
+***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo *****
+
+What is the VESA(TM) Coordinated Video Timings (CVT)?
+
+From the VESA(TM) Website:
+
+     "The purpose of CVT is to provide a method for generating a consistent
+      and coordinated set of standard formats, display refresh rates, and
+      timing specifications for computer display products, both those
+      employing CRTs, and those using other display technologies. The
+      intention of CVT is to give both source and display manufacturers a
+      common set of tools to enable new timings to be developed in a
+      consistent manner that ensures greater compatibility."
+
+This is the third standard approved by VESA(TM) concerning video timings.  The
+first was the Discrete Video Timings (DVT) which is  a collection of
+pre-defined modes approved by VESA(TM).  The second is the Generalized Timing
+Formula (GTF) which is an algorithm to calculate the timings, given the
+pixelclock, the horizontal sync frequency, or the vertical refresh rate.
+
+The GTF is limited by the fact that it is designed mainly for CRT displays.
+It artificially increases the pixelclock because of its high blanking
+requirement. This is inappropriate for digital display interface with its high
+data rate which requires that it conserves the pixelclock as much as possible.
+Also, GTF does not take into account the aspect ratio of the display.
+
+The CVT addresses these limitations.  If used with CRT's, the formula used
+is a derivation of GTF with a few modifications.  If used with digital
+displays, the "reduced blanking" calculation can be used.
+
+From the framebuffer subsystem perspective, new formats need not be added
+to the global mode database whenever a new mode is released by display
+manufacturers. Specifying for CVT will work for most, if not all, relatively
+new CRT displays and probably with most flatpanels, if 'reduced blanking'
+calculation is specified.  (The CVT compatibility of the display can be
+determined from its EDID. The version 1.3 of the EDID has extra 128-byte
+blocks where additional timing information is placed.  As of this time, there
+is no support yet in the layer to parse this additional blocks.)
+
+CVT also introduced a new naming convention (should be seen from dmesg output):
+
+    <pix>M<a>[-R]
+
+    where: pix = total amount of pixels in MB (xres x yres)
+           M   = always present
+           a   = aspect ratio (3 - 4:3; 4 - 5:4; 9 - 15:9, 16:9; A - 16:10)
+          -R   = reduced blanking
+
+         example:  .48M3-R - 800x600 with reduced blanking
+
+Note: VESA(TM) has restrictions on what is a standard CVT timing:
+
+      - aspect ratio can only be one of the above values
+      - acceptable refresh rates are 50, 60, 70 or 85 Hz only
+      - if reduced blanking, the refresh rate must be at 60Hz
+
+If one of the above are not satisfied, the kernel will print a warning but the
+timings will still be calculated.
+
+***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo *****
+
 To find a suitable video mode, you just call
 
 int __init fb_find_mode(struct fb_var_screeninfo *var,
diff --git a/Documentation/filesystems/files.txt b/Documentation/filesystems/files.txt
new file mode 100644 (file)
index 0000000..8c206f4
--- /dev/null
@@ -0,0 +1,123 @@
+File management in the Linux kernel
+-----------------------------------
+
+This document describes how locking for files (struct file)
+and file descriptor table (struct files) works.
+
+Up until 2.6.12, the file descriptor table has been protected
+with a lock (files->file_lock) and reference count (files->count).
+->file_lock protected accesses to all the file related fields
+of the table. ->count was used for sharing the file descriptor
+table between tasks cloned with CLONE_FILES flag. Typically
+this would be the case for posix threads. As with the common
+refcounting model in the kernel, the last task doing
+a put_files_struct() frees the file descriptor (fd) table.
+The files (struct file) themselves are protected using
+reference count (->f_count).
+
+In the new lock-free model of file descriptor management,
+the reference counting is similar, but the locking is
+based on RCU. The file descriptor table contains multiple
+elements - the fd sets (open_fds and close_on_exec, the
+array of file pointers, the sizes of the sets and the array
+etc.). In order for the updates to appear atomic to
+a lock-free reader, all the elements of the file descriptor
+table are in a separate structure - struct fdtable.
+files_struct contains a pointer to struct fdtable through
+which the actual fd table is accessed. Initially the
+fdtable is embedded in files_struct itself. On a subsequent
+expansion of fdtable, a new fdtable structure is allocated
+and files->fdtab points to the new structure. The fdtable
+structure is freed with RCU and lock-free readers either
+see the old fdtable or the new fdtable making the update
+appear atomic. Here are the locking rules for
+the fdtable structure -
+
+1. All references to the fdtable must be done through
+   the files_fdtable() macro :
+
+       struct fdtable *fdt;
+
+       rcu_read_lock();
+
+       fdt = files_fdtable(files);
+       ....
+       if (n <= fdt->max_fds)
+               ....
+       ...
+       rcu_read_unlock();
+
+   files_fdtable() uses rcu_dereference() macro which takes care of
+   the memory barrier requirements for lock-free dereference.
+   The fdtable pointer must be read within the read-side
+   critical section.
+
+2. Reading of the fdtable as described above must be protected
+   by rcu_read_lock()/rcu_read_unlock().
+
+3. For any update to the the fd table, files->file_lock must
+   be held.
+
+4. To look up the file structure given an fd, a reader
+   must use either fcheck() or fcheck_files() APIs. These
+   take care of barrier requirements due to lock-free lookup.
+   An example :
+
+       struct file *file;
+
+       rcu_read_lock();
+       file = fcheck(fd);
+       if (file) {
+               ...
+       }
+       ....
+       rcu_read_unlock();
+
+5. Handling of the file structures is special. Since the look-up
+   of the fd (fget()/fget_light()) are lock-free, it is possible
+   that look-up may race with the last put() operation on the
+   file structure. This is avoided using the rcuref APIs
+   on ->f_count :
+
+       rcu_read_lock();
+       file = fcheck_files(files, fd);
+       if (file) {
+               if (rcuref_inc_lf(&file->f_count))
+                       *fput_needed = 1;
+               else
+               /* Didn't get the reference, someone's freed */
+                       file = NULL;
+       }
+       rcu_read_unlock();
+       ....
+       return file;
+
+   rcuref_inc_lf() detects if refcounts is already zero or
+   goes to zero during increment. If it does, we fail
+   fget()/fget_light().
+
+6. Since both fdtable and file structures can be looked up
+   lock-free, they must be installed using rcu_assign_pointer()
+   API. If they are looked up lock-free, rcu_dereference()
+   must be used. However it is advisable to use files_fdtable()
+   and fcheck()/fcheck_files() which take care of these issues.
+
+7. While updating, the fdtable pointer must be looked up while
+   holding files->file_lock. If ->file_lock is dropped, then
+   another thread expand the files thereby creating a new
+   fdtable and making the earlier fdtable pointer stale.
+   For example :
+
+       spin_lock(&files->file_lock);
+       fd = locate_fd(files, file, start);
+       if (fd >= 0) {
+               /* locate_fd() may have expanded fdtable, load the ptr */
+               fdt = files_fdtable(files);
+               FD_SET(fd, fdt->open_fds);
+               FD_CLR(fd, fdt->close_on_exec);
+               spin_unlock(&files->file_lock);
+       .....
+
+   Since locate_fd() can drop ->file_lock (and reacquire ->file_lock),
+   the fdtable pointer (fdt) must be loaded after locate_fd().
+
diff --git a/Documentation/filesystems/fuse.txt b/Documentation/filesystems/fuse.txt
new file mode 100644 (file)
index 0000000..6b5741e
--- /dev/null
@@ -0,0 +1,315 @@
+Definitions
+~~~~~~~~~~~
+
+Userspace filesystem:
+
+  A filesystem in which data and metadata are provided by an ordinary
+  userspace process.  The filesystem can be accessed normally through
+  the kernel interface.
+
+Filesystem daemon:
+
+  The process(es) providing the data and metadata of the filesystem.
+
+Non-privileged mount (or user mount):
+
+  A userspace filesystem mounted by a non-privileged (non-root) user.
+  The filesystem daemon is running with the privileges of the mounting
+  user.  NOTE: this is not the same as mounts allowed with the "user"
+  option in /etc/fstab, which is not discussed here.
+
+Mount owner:
+
+  The user who does the mounting.
+
+User:
+
+  The user who is performing filesystem operations.
+
+What is FUSE?
+~~~~~~~~~~~~~
+
+FUSE is a userspace filesystem framework.  It consists of a kernel
+module (fuse.ko), a userspace library (libfuse.*) and a mount utility
+(fusermount).
+
+One of the most important features of FUSE is allowing secure,
+non-privileged mounts.  This opens up new possibilities for the use of
+filesystems.  A good example is sshfs: a secure network filesystem
+using the sftp protocol.
+
+The userspace library and utilities are available from the FUSE
+homepage:
+
+  http://fuse.sourceforge.net/
+
+Mount options
+~~~~~~~~~~~~~
+
+'fd=N'
+
+  The file descriptor to use for communication between the userspace
+  filesystem and the kernel.  The file descriptor must have been
+  obtained by opening the FUSE device ('/dev/fuse').
+
+'rootmode=M'
+
+  The file mode of the filesystem's root in octal representation.
+
+'user_id=N'
+
+  The numeric user id of the mount owner.
+
+'group_id=N'
+
+  The numeric group id of the mount owner.
+
+'default_permissions'
+
+  By default FUSE doesn't check file access permissions, the
+  filesystem is free to implement it's access policy or leave it to
+  the underlying file access mechanism (e.g. in case of network
+  filesystems).  This option enables permission checking, restricting
+  access based on file mode.  This is option is usually useful
+  together with the 'allow_other' mount option.
+
+'allow_other'
+
+  This option overrides the security measure restricting file access
+  to the user mounting the filesystem.  This option is by default only
+  allowed to root, but this restriction can be removed with a
+  (userspace) configuration option.
+
+'max_read=N'
+
+  With this option the maximum size of read operations can be set.
+  The default is infinite.  Note that the size of read requests is
+  limited anyway to 32 pages (which is 128kbyte on i386).
+
+How do non-privileged mounts work?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Since the mount() system call is a privileged operation, a helper
+program (fusermount) is needed, which is installed setuid root.
+
+The implication of providing non-privileged mounts is that the mount
+owner must not be able to use this capability to compromise the
+system.  Obvious requirements arising from this are:
+
+ A) mount owner should not be able to get elevated privileges with the
+    help of the mounted filesystem
+
+ B) mount owner should not get illegitimate access to information from
+    other users' and the super user's processes
+
+ C) mount owner should not be able to induce undesired behavior in
+    other users' or the super user's processes
+
+How are requirements fulfilled?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ A) The mount owner could gain elevated privileges by either:
+
+     1) creating a filesystem containing a device file, then opening
+       this device
+
+     2) creating a filesystem containing a suid or sgid application,
+       then executing this application
+
+    The solution is not to allow opening device files and ignore
+    setuid and setgid bits when executing programs.  To ensure this
+    fusermount always adds "nosuid" and "nodev" to the mount options
+    for non-privileged mounts.
+
+ B) If another user is accessing files or directories in the
+    filesystem, the filesystem daemon serving requests can record the
+    exact sequence and timing of operations performed.  This
+    information is otherwise inaccessible to the mount owner, so this
+    counts as an information leak.
+
+    The solution to this problem will be presented in point 2) of C).
+
+ C) There are several ways in which the mount owner can induce
+    undesired behavior in other users' processes, such as:
+
+     1) mounting a filesystem over a file or directory which the mount
+        owner could otherwise not be able to modify (or could only
+        make limited modifications).
+
+        This is solved in fusermount, by checking the access
+        permissions on the mountpoint and only allowing the mount if
+        the mount owner can do unlimited modification (has write
+        access to the mountpoint, and mountpoint is not a "sticky"
+        directory)
+
+     2) Even if 1) is solved the mount owner can change the behavior
+        of other users' processes.
+
+         i) It can slow down or indefinitely delay the execution of a
+           filesystem operation creating a DoS against the user or the
+           whole system.  For example a suid application locking a
+           system file, and then accessing a file on the mount owner's
+           filesystem could be stopped, and thus causing the system
+           file to be locked forever.
+
+         ii) It can present files or directories of unlimited length, or
+           directory structures of unlimited depth, possibly causing a
+           system process to eat up diskspace, memory or other
+           resources, again causing DoS.
+
+       The solution to this as well as B) is not to allow processes
+       to access the filesystem, which could otherwise not be
+       monitored or manipulated by the mount owner.  Since if the
+       mount owner can ptrace a process, it can do all of the above
+       without using a FUSE mount, the same criteria as used in
+       ptrace can be used to check if a process is allowed to access
+       the filesystem or not.
+
+       Note that the ptrace check is not strictly necessary to
+       prevent B/2/i, it is enough to check if mount owner has enough
+       privilege to send signal to the process accessing the
+       filesystem, since SIGSTOP can be used to get a similar effect.
+
+I think these limitations are unacceptable?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If a sysadmin trusts the users enough, or can ensure through other
+measures, that system processes will never enter non-privileged
+mounts, it can relax the last limitation with a "user_allow_other"
+config option.  If this config option is set, the mounting user can
+add the "allow_other" mount option which disables the check for other
+users' processes.
+
+Kernel - userspace interface
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following diagram shows how a filesystem operation (in this
+example unlink) is performed in FUSE.
+
+NOTE: everything in this description is greatly simplified
+
+ |  "rm /mnt/fuse/file"               |  FUSE filesystem daemon
+ |                                    |
+ |                                    |  >sys_read()
+ |                                    |    >fuse_dev_read()
+ |                                    |      >request_wait()
+ |                                    |        [sleep on fc->waitq]
+ |                                    |
+ |  >sys_unlink()                     |
+ |    >fuse_unlink()                  |
+ |      [get request from             |
+ |       fc->unused_list]             |
+ |      >request_send()               |
+ |        [queue req on fc->pending]  |
+ |        [wake up fc->waitq]         |        [woken up]
+ |        >request_wait_answer()      |
+ |          [sleep on req->waitq]     |
+ |                                    |      <request_wait()
+ |                                    |      [remove req from fc->pending]
+ |                                    |      [copy req to read buffer]
+ |                                    |      [add req to fc->processing]
+ |                                    |    <fuse_dev_read()
+ |                                    |  <sys_read()
+ |                                    |
+ |                                    |  [perform unlink]
+ |                                    |
+ |                                    |  >sys_write()
+ |                                    |    >fuse_dev_write()
+ |                                    |      [look up req in fc->processing]
+ |                                    |      [remove from fc->processing]
+ |                                    |      [copy write buffer to req]
+ |          [woken up]                |      [wake up req->waitq]
+ |                                    |    <fuse_dev_write()
+ |                                    |  <sys_write()
+ |        <request_wait_answer()      |
+ |      <request_send()               |
+ |      [add request to               |
+ |       fc->unused_list]             |
+ |    <fuse_unlink()                  |
+ |  <sys_unlink()                     |
+
+There are a couple of ways in which to deadlock a FUSE filesystem.
+Since we are talking about unprivileged userspace programs,
+something must be done about these.
+
+Scenario 1 -  Simple deadlock
+-----------------------------
+
+ |  "rm /mnt/fuse/file"               |  FUSE filesystem daemon
+ |                                    |
+ |  >sys_unlink("/mnt/fuse/file")     |
+ |    [acquire inode semaphore        |
+ |     for "file"]                    |
+ |    >fuse_unlink()                  |
+ |      [sleep on req->waitq]         |
+ |                                    |  <sys_read()
+ |                                    |  >sys_unlink("/mnt/fuse/file")
+ |                                    |    [acquire inode semaphore
+ |                                    |     for "file"]
+ |                                    |    *DEADLOCK*
+
+The solution for this is to allow requests to be interrupted while
+they are in userspace:
+
+ |      [interrupted by signal]       |
+ |    <fuse_unlink()                  |
+ |    [release semaphore]             |    [semaphore acquired]
+ |  <sys_unlink()                     |
+ |                                    |    >fuse_unlink()
+ |                                    |      [queue req on fc->pending]
+ |                                    |      [wake up fc->waitq]
+ |                                    |      [sleep on req->waitq]
+
+If the filesystem daemon was single threaded, this will stop here,
+since there's no other thread to dequeue and execute the request.
+In this case the solution is to kill the FUSE daemon as well.  If
+there are multiple serving threads, you just have to kill them as
+long as any remain.
+
+Moral: a filesystem which deadlocks, can soon find itself dead.
+
+Scenario 2 - Tricky deadlock
+----------------------------
+
+This one needs a carefully crafted filesystem.  It's a variation on
+the above, only the call back to the filesystem is not explicit,
+but is caused by a pagefault.
+
+ |  Kamikaze filesystem thread 1      |  Kamikaze filesystem thread 2
+ |                                    |
+ |  [fd = open("/mnt/fuse/file")]     |  [request served normally]
+ |  [mmap fd to 'addr']               |
+ |  [close fd]                        |  [FLUSH triggers 'magic' flag]
+ |  [read a byte from addr]           |
+ |    >do_page_fault()                |
+ |      [find or create page]         |
+ |      [lock page]                   |
+ |      >fuse_readpage()              |
+ |         [queue READ request]       |
+ |         [sleep on req->waitq]      |
+ |                                    |  [read request to buffer]
+ |                                    |  [create reply header before addr]
+ |                                    |  >sys_write(addr - headerlength)
+ |                                    |    >fuse_dev_write()
+ |                                    |      [look up req in fc->processing]
+ |                                    |      [remove from fc->processing]
+ |                                    |      [copy write buffer to req]
+ |                                    |        >do_page_fault()
+ |                                    |           [find or create page]
+ |                                    |           [lock page]
+ |                                    |           * DEADLOCK *
+
+Solution is again to let the the request be interrupted (not
+elaborated further).
+
+An additional problem is that while the write buffer is being
+copied to the request, the request must not be interrupted.  This
+is because the destination address of the copy may not be valid
+after the request is interrupted.
+
+This is solved with doing the copy atomically, and allowing
+interruption while the page(s) belonging to the write buffer are
+faulted with get_user_pages().  The 'req->locked' flag indicates
+when the copy is taking place, and interruption is delayed until
+this flag is unset.
+
index 5024ba7a592c065820216ecf21ee862355170d41..d4773565ea2f20fabf868505f8b48f2ea7b6295a 100644 (file)
@@ -1241,16 +1241,38 @@ swap-intensive.
 overcommit_memory
 -----------------
 
-This file  contains  one  value.  The following algorithm is used to decide if
-there's enough  memory:  if  the  value of overcommit_memory is positive, then
-there's always  enough  memory. This is a useful feature, since programs often
-malloc() huge  amounts  of  memory 'just in case', while they only use a small
-part of  it.  Leaving  this value at 0 will lead to the failure of such a huge
-malloc(), when in fact the system has enough memory for the program to run.
-
-On the  other  hand,  enabling this feature can cause you to run out of memory
-and thrash the system to death, so large and/or important servers will want to
-set this value to 0.
+Controls overcommit of system memory, possibly allowing processes
+to allocate (but not use) more memory than is actually available.
+
+
+0      -       Heuristic overcommit handling. Obvious overcommits of
+               address space are refused. Used for a typical system. It
+               ensures a seriously wild allocation fails while allowing
+               overcommit to reduce swap usage.  root is allowed to
+               allocate slighly more memory in this mode. This is the
+               default.
+
+1      -       Always overcommit. Appropriate for some scientific
+               applications.
+
+2      -       Don't overcommit. The total address space commit
+               for the system is not permitted to exceed swap plus a
+               configurable percentage (default is 50) of physical RAM.
+               Depending on the percentage you use, in most situations
+               this means a process will not be killed while attempting
+               to use already-allocated memory but will receive errors
+               on memory allocation as appropriate.
+
+overcommit_ratio
+----------------
+
+Percentage of physical memory size to include in overcommit calculations
+(see above.)
+
+Memory allocation limit = swapspace + physmem * (overcommit_ratio / 100)
+
+       swapspace = total size of all swap areas
+       physmem = size of physical memory in system
 
 nr_hugepages and hugetlb_shm_group
 ----------------------------------
diff --git a/Documentation/filesystems/v9fs.txt b/Documentation/filesystems/v9fs.txt
new file mode 100644 (file)
index 0000000..4e92feb
--- /dev/null
@@ -0,0 +1,95 @@
+                       V9FS: 9P2000 for Linux
+                       ======================
+
+ABOUT
+=====
+
+v9fs is a Unix implementation of the Plan 9 9p remote filesystem protocol.
+
+This software was originally developed by Ron Minnich <rminnich@lanl.gov>
+and Maya Gokhale <maya@lanl.gov>.  Additional development by Greg Watson
+<gwatson@lanl.gov> and most recently Eric Van Hensbergen
+<ericvh@gmail.com> and Latchesar Ionkov <lucho@ionkov.net>.
+
+USAGE
+=====
+
+For remote file server:
+
+       mount -t 9P 10.10.1.2 /mnt/9
+
+For Plan 9 From User Space applications (http://swtch.com/plan9)
+
+       mount -t 9P `namespace`/acme /mnt/9 -o proto=unix,name=$USER
+
+OPTIONS
+=======
+
+  proto=name   select an alternative transport.  Valid options are
+               currently:
+                       unix - specifying a named pipe mount point
+                       tcp  - specifying a normal TCP/IP connection
+                       fd   - used passed file descriptors for connection
+                                (see rfdno and wfdno)
+
+  name=name    user name to attempt mount as on the remote server.  The
+               server may override or ignore this value.  Certain user
+               names may require authentication.
+
+  aname=name   aname specifies the file tree to access when the server is
+               offering several exported file systems.
+
+  debug=n      specifies debug level.  The debug level is a bitmask.
+                       0x01 = display verbose error messages
+                       0x02 = developer debug (DEBUG_CURRENT)
+                       0x04 = display 9P trace
+                       0x08 = display VFS trace
+                       0x10 = display Marshalling debug
+                       0x20 = display RPC debug
+                       0x40 = display transport debug
+                       0x80 = display allocation debug
+
+  rfdno=n      the file descriptor for reading with proto=fd
+
+  wfdno=n      the file descriptor for writing with proto=fd
+
+  maxdata=n    the number of bytes to use for 9P packet payload (msize)
+
+  port=n       port to connect to on the remote server
+
+  timeout=n    request timeouts (in ms) (default 60000ms)
+
+  noextend     force legacy mode (no 9P2000.u semantics)
+
+  uid          attempt to mount as a particular uid
+
+  gid          attempt to mount with a particular gid
+
+  afid         security channel - used by Plan 9 authentication protocols
+
+  nodevmap     do not map special files - represent them as normal files.
+               This can be used to share devices/named pipes/sockets between
+               hosts.  This functionality will be expanded in later versions.
+
+RESOURCES
+=========
+
+The Linux version of the 9P server, along with some client-side utilities
+can be found at http://v9fs.sf.net (along with a CVS repository of the
+development branch of this module).  There are user and developer mailing
+lists here, as well as a bug-tracker.
+
+For more information on the Plan 9 Operating System check out
+http://plan9.bell-labs.com/plan9
+
+For information on Plan 9 from User Space (Plan 9 applications and libraries
+ported to Linux/BSD/OSX/etc) check out http://swtch.com/plan9
+
+
+STATUS
+======
+
+The 2.6 kernel support is working on PPC and x86.
+
+PLEASE USE THE SOURCEFORGE BUG-TRACKER TO REPORT PROBLEMS.
+
index 3f318dd44c775fa21a5a407b85032e4683e03905..f042c12e0ed2d24683e1b83ddfd130b561ad0e1b 100644 (file)
@@ -1,35 +1,27 @@
-/* -*- auto-fill -*-                                                         */
 
-               Overview of the Virtual File System
+             Overview of the Linux Virtual File System
 
-               Richard Gooch <rgooch@atnf.csiro.au>
+       Original author: Richard Gooch <rgooch@atnf.csiro.au>
 
-                             5-JUL-1999
+                 Last updated on August 25, 2005
 
+  Copyright (C) 1999 Richard Gooch
+  Copyright (C) 2005 Pekka Enberg
 
-Conventions used in this document                                     <section>
-=================================
+  This file is released under the GPLv2.
 
-Each section in this document will have the string "<section>" at the
-right-hand side of the section title. Each subsection will have
-"<subsection>" at the right-hand side. These strings are meant to make
-it easier to search through the document.
 
-NOTE that the master copy of this document is available online at:
-http://www.atnf.csiro.au/~rgooch/linux/docs/vfs.txt
-
-
-What is it?                                                           <section>
+What is it?
 ===========
 
 The Virtual File System (otherwise known as the Virtual Filesystem
 Switch) is the software layer in the kernel that provides the
 filesystem interface to userspace programs. It also provides an
 abstraction within the kernel which allows different filesystem
-implementations to co-exist.
+implementations to coexist.
 
 
-A Quick Look At How It Works                                          <section>
+A Quick Look At How It Works
 ============================
 
 In this section I'll briefly describe how things work, before
@@ -38,7 +30,8 @@ when user programs open and manipulate files, and then look from the
 other view which is how a filesystem is supported and subsequently
 mounted.
 
-Opening a File                                                     <subsection>
+
+Opening a File
 --------------
 
 The VFS implements the open(2), stat(2), chmod(2) and similar system
@@ -77,7 +70,7 @@ back to userspace.
 
 Opening a file requires another operation: allocation of a file
 structure (this is the kernel-side implementation of file
-descriptors). The freshly allocated file structure is initialised with
+descriptors). The freshly allocated file structure is initialized with
 a pointer to the dentry and a set of file operation member functions.
 These are taken from the inode data. The open() file method is then
 called so the specific filesystem implementation can do it's work. You
@@ -102,7 +95,8 @@ filesystem or driver code at the same time, on different
 processors. You should ensure that access to shared resources is
 protected by appropriate locks.
 
-Registering and Mounting a Filesystem                              <subsection>
+
+Registering and Mounting a Filesystem
 -------------------------------------
 
 If you want to support a new kind of filesystem in the kernel, all you
@@ -123,17 +117,21 @@ updated to point to the root inode for the new filesystem.
 It's now time to look at things in more detail.
 
 
-struct file_system_type                                               <section>
+struct file_system_type
 =======================
 
-This describes the filesystem. As of kernel 2.1.99, the following
+This describes the filesystem. As of kernel 2.6.13, the following
 members are defined:
 
 struct file_system_type {
        const char *name;
        int fs_flags;
-       struct super_block *(*read_super) (struct super_block *, void *, int);
-       struct file_system_type * next;
+        struct super_block *(*get_sb) (struct file_system_type *, int,
+                                       const char *, void *);
+        void (*kill_sb) (struct super_block *);
+        struct module *owner;
+        struct file_system_type * next;
+        struct list_head fs_supers;
 };
 
   name: the name of the filesystem type, such as "ext2", "iso9660",
@@ -141,51 +139,97 @@ struct file_system_type {
 
   fs_flags: various flags (i.e. FS_REQUIRES_DEV, FS_NO_DCACHE, etc.)
 
-  read_super: the method to call when a new instance of this
+  get_sb: the method to call when a new instance of this
        filesystem should be mounted
 
-  next: for internal VFS use: you should initialise this to NULL
+  kill_sb: the method to call when an instance of this filesystem
+       should be unmounted
+
+  owner: for internal VFS use: you should initialize this to THIS_MODULE in
+       most cases.
 
-The read_super() method has the following arguments:
+  next: for internal VFS use: you should initialize this to NULL
+
+The get_sb() method has the following arguments:
 
   struct super_block *sb: the superblock structure. This is partially
-       initialised by the VFS and the rest must be initialised by the
-       read_super() method
+       initialized by the VFS and the rest must be initialized by the
+       get_sb() method
+
+  int flags: mount flags
+
+  const char *dev_name: the device name we are mounting.
 
   void *data: arbitrary mount options, usually comes as an ASCII
        string
 
   int silent: whether or not to be silent on error
 
-The read_super() method must determine if the block device specified
+The get_sb() method must determine if the block device specified
 in the superblock contains a filesystem of the type the method
 supports. On success the method returns the superblock pointer, on
 failure it returns NULL.
 
 The most interesting member of the superblock structure that the
-read_super() method fills in is the "s_op" field. This is a pointer to
+get_sb() method fills in is the "s_op" field. This is a pointer to
 a "struct super_operations" which describes the next level of the
 filesystem implementation.
 
+Usually, a filesystem uses generic one of the generic get_sb()
+implementations and provides a fill_super() method instead. The
+generic methods are:
+
+  get_sb_bdev: mount a filesystem residing on a block device
 
-struct super_operations                                               <section>
+  get_sb_nodev: mount a filesystem that is not backed by a device
+
+  get_sb_single: mount a filesystem which shares the instance between
+       all mounts
+
+A fill_super() method implementation has the following arguments:
+
+  struct super_block *sb: the superblock structure. The method fill_super()
+       must initialize this properly.
+
+  void *data: arbitrary mount options, usually comes as an ASCII
+       string
+
+  int silent: whether or not to be silent on error
+
+
+struct super_operations
 =======================
 
 This describes how the VFS can manipulate the superblock of your
-filesystem. As of kernel 2.1.99, the following members are defined:
+filesystem. As of kernel 2.6.13, the following members are defined:
 
 struct super_operations {
-       void (*read_inode) (struct inode *);
-       int (*write_inode) (struct inode *, int);
-       void (*put_inode) (struct inode *);
-       void (*drop_inode) (struct inode *);
-       void (*delete_inode) (struct inode *);
-       int (*notify_change) (struct dentry *, struct iattr *);
-       void (*put_super) (struct super_block *);
-       void (*write_super) (struct super_block *);
-       int (*statfs) (struct super_block *, struct statfs *, int);
-       int (*remount_fs) (struct super_block *, int *, char *);
-       void (*clear_inode) (struct inode *);
+        struct inode *(*alloc_inode)(struct super_block *sb);
+        void (*destroy_inode)(struct inode *);
+
+        void (*read_inode) (struct inode *);
+
+        void (*dirty_inode) (struct inode *);
+        int (*write_inode) (struct inode *, int);
+        void (*put_inode) (struct inode *);
+        void (*drop_inode) (struct inode *);
+        void (*delete_inode) (struct inode *);
+        void (*put_super) (struct super_block *);
+        void (*write_super) (struct super_block *);
+        int (*sync_fs)(struct super_block *sb, int wait);
+        void (*write_super_lockfs) (struct super_block *);
+        void (*unlockfs) (struct super_block *);
+        int (*statfs) (struct super_block *, struct kstatfs *);
+        int (*remount_fs) (struct super_block *, int *, char *);
+        void (*clear_inode) (struct inode *);
+        void (*umount_begin) (struct super_block *);
+
+        void (*sync_inodes) (struct super_block *sb,
+                                struct writeback_control *wbc);
+        int (*show_options)(struct seq_file *, struct vfsmount *);
+
+        ssize_t (*quota_read)(struct super_block *, int, char *, size_t, loff_t);
+        ssize_t (*quota_write)(struct super_block *, int, const char *, size_t, loff_t);
 };
 
 All methods are called without any locks being held, unless otherwise
@@ -193,43 +237,62 @@ noted. This means that most methods can block safely. All methods are
 only called from a process context (i.e. not from an interrupt handler
 or bottom half).
 
+  alloc_inode: this method is called by inode_alloc() to allocate memory
+       for struct inode and initialize it.
+
+  destroy_inode: this method is called by destroy_inode() to release
+       resources allocated for struct inode.
+
   read_inode: this method is called to read a specific inode from the
-       mounted filesystem. The "i_ino" member in the "struct inode"
-       will be initialised by the VFS to indicate which inode to
-       read. Other members are filled in by this method
+        mounted filesystem.  The i_ino member in the struct inode is
+       initialized by the VFS to indicate which inode to read. Other
+       members are filled in by this method.
+
+       You can set this to NULL and use iget5_locked() instead of iget()
+       to read inodes.  This is necessary for filesystems for which the
+       inode number is not sufficient to identify an inode.
+
+  dirty_inode: this method is called by the VFS to mark an inode dirty.
 
   write_inode: this method is called when the VFS needs to write an
        inode to disc.  The second parameter indicates whether the write
        should be synchronous or not, not all filesystems check this flag.
 
   put_inode: called when the VFS inode is removed from the inode
-       cache. This method is optional
+       cache.
 
   drop_inode: called when the last access to the inode is dropped,
        with the inode_lock spinlock held.
 
-       This method should be either NULL (normal unix filesystem
+       This method should be either NULL (normal UNIX filesystem
        semantics) or "generic_delete_inode" (for filesystems that do not
        want to cache inodes - causing "delete_inode" to always be
        called regardless of the value of i_nlink)
 
-       The "generic_delete_inode()" behaviour is equivalent to the
+       The "generic_delete_inode()" behavior is equivalent to the
        old practice of using "force_delete" in the put_inode() case,
        but does not have the races that the "force_delete()" approach
        had. 
 
   delete_inode: called when the VFS wants to delete an inode
 
-  notify_change: called when VFS inode attributes are changed. If this
-       is NULL the VFS falls back to the write_inode() method. This
-       is called with the kernel lock held
-
   put_super: called when the VFS wishes to free the superblock
        (i.e. unmount). This is called with the superblock lock held
 
   write_super: called when the VFS superblock needs to be written to
        disc. This method is optional
 
+  sync_fs: called when VFS is writing out all dirty data associated with
+       a superblock. The second parameter indicates whether the method
+       should wait until the write out has been completed. Optional.
+
+  write_super_lockfs: called when VFS is locking a filesystem and forcing
+       it into a consistent state.  This function is currently used by the
+       Logical Volume Manager (LVM).
+
+  unlockfs: called when VFS is unlocking a filesystem and making it writable
+       again.
+
   statfs: called when the VFS needs to get filesystem statistics. This
        is called with the kernel lock held
 
@@ -238,21 +301,31 @@ or bottom half).
 
   clear_inode: called then the VFS clears the inode. Optional
 
+  umount_begin: called when the VFS is unmounting a filesystem.
+
+  sync_inodes: called when the VFS is writing out dirty data associated with
+       a superblock.
+
+  show_options: called by the VFS to show mount options for /proc/<pid>/mounts.
+
+  quota_read: called by the VFS to read from filesystem quota file.
+
+  quota_write: called by the VFS to write to filesystem quota file.
+
 The read_inode() method is responsible for filling in the "i_op"
 field. This is a pointer to a "struct inode_operations" which
 describes the methods that can be performed on individual inodes.
 
 
-struct inode_operations                                               <section>
+struct inode_operations
 =======================
 
 This describes how the VFS can manipulate an inode in your
-filesystem. As of kernel 2.1.99, the following members are defined:
+filesystem. As of kernel 2.6.13, the following members are defined:
 
 struct inode_operations {
-       struct file_operations * default_file_ops;
-       int (*create) (struct inode *,struct dentry *,int);
-       int (*lookup) (struct inode *,struct dentry *);
+       int (*create) (struct inode *,struct dentry *,int, struct nameidata *);
+       struct dentry * (*lookup) (struct inode *,struct dentry *, struct nameidata *);
        int (*link) (struct dentry *,struct inode *,struct dentry *);
        int (*unlink) (struct inode *,struct dentry *);
        int (*symlink) (struct inode *,struct dentry *,const char *);
@@ -261,25 +334,22 @@ struct inode_operations {
        int (*mknod) (struct inode *,struct dentry *,int,dev_t);
        int (*rename) (struct inode *, struct dentry *,
                        struct inode *, struct dentry *);
-       int (*readlink) (struct dentry *, char *,int);
-       struct dentry * (*follow_link) (struct dentry *, struct dentry *);
-       int (*readpage) (struct file *, struct page *);
-       int (*writepage) (struct page *page, struct writeback_control *wbc);
-       int (*bmap) (struct inode *,int);
+       int (*readlink) (struct dentry *, char __user *,int);
+        void * (*follow_link) (struct dentry *, struct nameidata *);
+        void (*put_link) (struct dentry *, struct nameidata *, void *);
        void (*truncate) (struct inode *);
-       int (*permission) (struct inode *, int);
-       int (*smap) (struct inode *,int);
-       int (*updatepage) (struct file *, struct page *, const char *,
-                               unsigned long, unsigned int, int);
-       int (*revalidate) (struct dentry *);
+       int (*permission) (struct inode *, int, struct nameidata *);
+       int (*setattr) (struct dentry *, struct iattr *);
+       int (*getattr) (struct vfsmount *mnt, struct dentry *, struct kstat *);
+       int (*setxattr) (struct dentry *, const char *,const void *,size_t,int);
+       ssize_t (*getxattr) (struct dentry *, const char *, void *, size_t);
+       ssize_t (*listxattr) (struct dentry *, char *, size_t);
+       int (*removexattr) (struct dentry *, const char *);
 };
 
 Again, all methods are called without any locks being held, unless
 otherwise noted.
 
-  default_file_ops: this is a pointer to a "struct file_operations"
-       which describes how to open and then manipulate open files
-
   create: called by the open(2) and creat(2) system calls. Only
        required if you want to support regular files. The dentry you
        get should not have an inode (i.e. it should be a negative
@@ -328,31 +398,143 @@ otherwise noted.
        you want to support reading symbolic links
 
   follow_link: called by the VFS to follow a symbolic link to the
-       inode it points to. Only required if you want to support
-       symbolic links
+       inode it points to.  Only required if you want to support
+       symbolic links.  This function returns a void pointer cookie
+       that is passed to put_link().
+
+  put_link: called by the VFS to release resources allocated by
+       follow_link().  The cookie returned by follow_link() is passed to
+       to this function as the last parameter.  It is used by filesystems
+       such as NFS where page cache is not stable (i.e. page that was
+       installed when the symbolic link walk started might not be in the
+       page cache at the end of the walk).
+
+  truncate: called by the VFS to change the size of a file.  The i_size
+       field of the inode is set to the desired size by the VFS before
+       this function is called.  This function is called by the truncate(2)
+       system call and related functionality.
+
+  permission: called by the VFS to check for access rights on a POSIX-like
+       filesystem.
+
+  setattr: called by the VFS to set attributes for a file.  This function is
+       called by chmod(2) and related system calls.
+
+  getattr: called by the VFS to get attributes of a file.  This function is
+       called by stat(2) and related system calls.
+
+  setxattr: called by the VFS to set an extended attribute for a file.
+       Extended attribute is a name:value pair associated with an inode. This
+       function is called by setxattr(2) system call.
+
+  getxattr: called by the VFS to retrieve the value of an extended attribute
+       name.  This function is called by getxattr(2) function call.
+
+  listxattr: called by the VFS to list all extended attributes for a given
+       file.  This function is called by listxattr(2) system call.
+
+  removexattr: called by the VFS to remove an extended attribute from a file.
+       This function is called by removexattr(2) system call.
+
+
+struct address_space_operations
+===============================
+
+This describes how the VFS can manipulate mapping of a file to page cache in
+your filesystem. As of kernel 2.6.13, the following members are defined:
+
+struct address_space_operations {
+       int (*writepage)(struct page *page, struct writeback_control *wbc);
+       int (*readpage)(struct file *, struct page *);
+       int (*sync_page)(struct page *);
+       int (*writepages)(struct address_space *, struct writeback_control *);
+       int (*set_page_dirty)(struct page *page);
+       int (*readpages)(struct file *filp, struct address_space *mapping,
+                       struct list_head *pages, unsigned nr_pages);
+       int (*prepare_write)(struct file *, struct page *, unsigned, unsigned);
+       int (*commit_write)(struct file *, struct page *, unsigned, unsigned);
+       sector_t (*bmap)(struct address_space *, sector_t);
+       int (*invalidatepage) (struct page *, unsigned long);
+       int (*releasepage) (struct page *, int);
+       ssize_t (*direct_IO)(int, struct kiocb *, const struct iovec *iov,
+                       loff_t offset, unsigned long nr_segs);
+       struct page* (*get_xip_page)(struct address_space *, sector_t,
+                       int);
+};
+
+  writepage: called by the VM write a dirty page to backing store.
+
+  readpage: called by the VM to read a page from backing store.
+
+  sync_page: called by the VM to notify the backing store to perform all
+       queued I/O operations for a page. I/O operations for other pages
+       associated with this address_space object may also be performed.
+
+  writepages: called by the VM to write out pages associated with the
+       address_space object.
+
+  set_page_dirty: called by the VM to set a page dirty.
+
+  readpages: called by the VM to read pages associated with the address_space
+       object.
 
+  prepare_write: called by the generic write path in VM to set up a write
+       request for a page.
 
-struct file_operations                                                <section>
+  commit_write: called by the generic write path in VM to write page to
+       its backing store.
+
+  bmap: called by the VFS to map a logical block offset within object to
+       physical block number. This method is use by for the legacy FIBMAP
+       ioctl. Other uses are discouraged.
+
+  invalidatepage: called by the VM on truncate to disassociate a page from its
+       address_space mapping.
+
+  releasepage: called by the VFS to release filesystem specific metadata from
+       a page.
+
+  direct_IO: called by the VM for direct I/O writes and reads.
+
+  get_xip_page: called by the VM to translate a block number to a page.
+       The page is valid until the corresponding filesystem is unmounted.
+       Filesystems that want to use execute-in-place (XIP) need to implement
+       it.  An example implementation can be found in fs/ext2/xip.c.
+
+
+struct file_operations
 ======================
 
 This describes how the VFS can manipulate an open file. As of kernel
-2.1.99, the following members are defined:
+2.6.13, the following members are defined:
 
 struct file_operations {
        loff_t (*llseek) (struct file *, loff_t, int);
-       ssize_t (*read) (struct file *, char *, size_t, loff_t *);
-       ssize_t (*write) (struct file *, const char *, size_t, loff_t *);
+       ssize_t (*read) (struct file *, char __user *, size_t, loff_t *);
+       ssize_t (*aio_read) (struct kiocb *, char __user *, size_t, loff_t);
+       ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);
+       ssize_t (*aio_write) (struct kiocb *, const char __user *, size_t, loff_t);
        int (*readdir) (struct file *, void *, filldir_t);
        unsigned int (*poll) (struct file *, struct poll_table_struct *);
        int (*ioctl) (struct inode *, struct file *, unsigned int, unsigned long);
+       long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
+       long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
        int (*mmap) (struct file *, struct vm_area_struct *);
        int (*open) (struct inode *, struct file *);
+       int (*flush) (struct file *);
        int (*release) (struct inode *, struct file *);
-       int (*fsync) (struct file *, struct dentry *);
-       int (*fasync) (struct file *, int);
-       int (*check_media_change) (kdev_t dev);
-       int (*revalidate) (kdev_t dev);
+       int (*fsync) (struct file *, struct dentry *, int datasync);
+       int (*aio_fsync) (struct kiocb *, int datasync);
+       int (*fasync) (int, struct file *, int);
        int (*lock) (struct file *, int, struct file_lock *);
+       ssize_t (*readv) (struct file *, const struct iovec *, unsigned long, loff_t *);
+       ssize_t (*writev) (struct file *, const struct iovec *, unsigned long, loff_t *);
+       ssize_t (*sendfile) (struct file *, loff_t *, size_t, read_actor_t, void *);
+       ssize_t (*sendpage) (struct file *, struct page *, int, size_t, loff_t *, int);
+       unsigned long (*get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long);
+       int (*check_flags)(int);
+       int (*dir_notify)(struct file *filp, unsigned long arg);
+       int (*flock) (struct file *, int, struct file_lock *);
 };
 
 Again, all methods are called without any locks being held, unless
@@ -362,8 +544,12 @@ otherwise noted.
 
   read: called by read(2) and related system calls
 
+  aio_read: called by io_submit(2) and other asynchronous I/O operations
+
   write: called by write(2) and related system calls
 
+  aio_write: called by io_submit(2) and other asynchronous I/O operations
+
   readdir: called when the VFS needs to read the directory contents
 
   poll: called by the VFS when a process wants to check if there is
@@ -372,18 +558,25 @@ otherwise noted.
 
   ioctl: called by the ioctl(2) system call
 
+  unlocked_ioctl: called by the ioctl(2) system call. Filesystems that do not
+       require the BKL should use this method instead of the ioctl() above.
+
+  compat_ioctl: called by the ioctl(2) system call when 32 bit system calls
+        are used on 64 bit kernels.
+
   mmap: called by the mmap(2) system call
 
   open: called by the VFS when an inode should be opened. When the VFS
-       opens a file, it creates a new "struct file" and initialises
-       the "f_op" file operations member with the "default_file_ops"
-       field in the inode structure. It then calls the open method
-       for the newly allocated file structure. You might think that
-       the open method really belongs in "struct inode_operations",
-       and you may be right. I think it's done the way it is because
-       it makes filesystems simpler to implement. The open() method
-       is a good place to initialise the "private_data" member in the
-       file structure if you want to point to a device structure
+       opens a file, it creates a new "struct file". It then calls the
+       open method for the newly allocated file structure. You might
+       think that the open method really belongs in
+       "struct inode_operations", and you may be right. I think it's
+       done the way it is because it makes filesystems simpler to
+       implement. The open() method is a good place to initialize the
+       "private_data" member in the file structure if you want to point
+       to a device structure
+
+  flush: called by the close(2) system call to flush a file
 
   release: called when the last reference to an open file is closed
 
@@ -392,6 +585,23 @@ otherwise noted.
   fasync: called by the fcntl(2) system call when asynchronous
        (non-blocking) mode is enabled for a file
 
+  lock: called by the fcntl(2) system call for F_GETLK, F_SETLK, and F_SETLKW
+       commands
+
+  readv: called by the readv(2) system call
+
+  writev: called by the writev(2) system call
+
+  sendfile: called by the sendfile(2) system call
+
+  get_unmapped_area: called by the mmap(2) system call
+
+  check_flags: called by the fcntl(2) system call for F_SETFL command
+
+  dir_notify: called by the fcntl(2) system call for F_NOTIFY command
+
+  flock: called by the flock(2) system call
+
 Note that the file operations are implemented by the specific
 filesystem in which the inode resides. When opening a device node
 (character or block special) most filesystems will call special
@@ -400,29 +610,28 @@ driver information. These support routines replace the filesystem file
 operations with those for the device driver, and then proceed to call
 the new open() method for the file. This is how opening a device file
 in the filesystem eventually ends up calling the device driver open()
-method. Note the devfs (the Device FileSystem) has a more direct path
-from device node to device driver (this is an unofficial kernel
-patch).
+method.
 
 
-Directory Entry Cache (dcache)                                        <section>
-------------------------------
+Directory Entry Cache (dcache)
+==============================
+
 
 struct dentry_operations
-========================
+------------------------
 
 This describes how a filesystem can overload the standard dentry
 operations. Dentries and the dcache are the domain of the VFS and the
 individual filesystem implementations. Device drivers have no business
 here. These methods may be set to NULL, as they are either optional or
-the VFS uses a default. As of kernel 2.1.99, the following members are
+the VFS uses a default. As of kernel 2.6.13, the following members are
 defined:
 
 struct dentry_operations {
-       int (*d_revalidate)(struct dentry *);
+       int (*d_revalidate)(struct dentry *, struct nameidata *);
        int (*d_hash) (struct dentry *, struct qstr *);
        int (*d_compare) (struct dentry *, struct qstr *, struct qstr *);
-       void (*d_delete)(struct dentry *);
+       int (*d_delete)(struct dentry *);
        void (*d_release)(struct dentry *);
        void (*d_iput)(struct dentry *, struct inode *);
 };
@@ -451,6 +660,7 @@ Each dentry has a pointer to its parent dentry, as well as a hash list
 of child dentries. Child dentries are basically like files in a
 directory.
 
+
 Directory Entry Cache APIs
 --------------------------
 
@@ -471,7 +681,7 @@ manipulate dentries:
        "d_delete" method is called
 
   d_drop: this unhashes a dentry from its parents hash list. A
-       subsequent call to dput() will dellocate the dentry if its
+       subsequent call to dput() will deallocate the dentry if its
        usage count drops to 0
 
   d_delete: delete a dentry. If there are no other open references to
@@ -507,16 +717,16 @@ up by walking the tree starting with the first component
 of the pathname and using that dentry along with the next
 component to look up the next level and so on. Since it
 is a frequent operation for workloads like multiuser
-environments and webservers, it is important to optimize
+environments and web servers, it is important to optimize
 this path.
 
 Prior to 2.5.10, dcache_lock was acquired in d_lookup and thus
 in every component during path look-up. Since 2.5.10 onwards,
-fastwalk algorithm changed this by holding the dcache_lock
+fast-walk algorithm changed this by holding the dcache_lock
 at the beginning and walking as many cached path component
-dentries as possible. This signficantly decreases the number
+dentries as possible. This significantly decreases the number
 of acquisition of dcache_lock. However it also increases the
-lock hold time signficantly and affects performance in large
+lock hold time significantly and affects performance in large
 SMP machines. Since 2.5.62 kernel, dcache has been using
 a new locking model that uses RCU to make dcache look-up
 lock-free.
@@ -527,7 +737,7 @@ protected the hash chain, d_child, d_alias, d_lru lists as well
 as d_inode and several other things like mount look-up. RCU-based
 changes affect only the way the hash chain is protected. For everything
 else the dcache_lock must be taken for both traversing as well as
-updating. The hash chain updations too take the dcache_lock.
+updating. The hash chain updates too take the dcache_lock.
 The significant change is the way d_lookup traverses the hash chain,
 it doesn't acquire the dcache_lock for this and rely on RCU to
 ensure that the dentry has not been *freed*.
@@ -535,14 +745,15 @@ ensure that the dentry has not been *freed*.
 
 Dcache locking details
 ----------------------
+
 For many multi-user workloads, open() and stat() on files are
 very frequently occurring operations. Both involve walking
 of path names to find the dentry corresponding to the
 concerned file. In 2.4 kernel, dcache_lock was held
 during look-up of each path component. Contention and
-cacheline bouncing of this global lock caused significant
+cache-line bouncing of this global lock caused significant
 scalability problems. With the introduction of RCU
-in linux kernel, this was worked around by making
+in Linux kernel, this was worked around by making
 the look-up of path components during path walking lock-free.
 
 
@@ -562,7 +773,7 @@ Some of the important changes are :
 2. Insertion of a dentry into the hash table is done using
    hlist_add_head_rcu() which take care of ordering the writes -
    the writes to the dentry must be visible before the dentry
-   is inserted. This works in conjuction with hlist_for_each_rcu()
+   is inserted. This works in conjunction with hlist_for_each_rcu()
    while walking the hash chain. The only requirement is that
    all initialization to the dentry must be done before hlist_add_head_rcu()
    since we don't have dcache_lock protection while traversing
@@ -584,7 +795,7 @@ Some of the important changes are :
    the same.  In some sense, dcache_rcu path walking looks like
    the pre-2.5.10 version.
 
-5. All dentry hash chain updations must take the dcache_lock as well as
+5. All dentry hash chain updates must take the dcache_lock as well as
    the per-dentry lock in that order. dput() does this to ensure
    that a dentry that has just been looked up in another CPU
    doesn't get deleted before dget() can be done on it.
@@ -640,10 +851,10 @@ handled as described below :
    Since we redo the d_parent check and compare name while holding
    d_lock, lock-free look-up will not race against d_move().
 
-4. There can be a theoritical race when a dentry keeps coming back
+4. There can be a theoretical race when a dentry keeps coming back
    to original bucket due to double moves. Due to this look-up may
    consider that it has never moved and can end up in a infinite loop.
-   But this is not any worse that theoritical livelocks we already
+   But this is not any worse that theoretical livelocks we already
    have in the kernel.
 
 
index 7ff213f4becd34d1f2a378c77f427aa3ac9c8033..1f5f7d28c9e6bf54e2b95d97f9399aed324b177f 100644 (file)
@@ -39,8 +39,7 @@ SETUP
    and apply http://lse.sourceforge.net/kdump/patches/kexec-tools-1.101-kdump.patch
    and after that build the source.
 
-2) Download and build the appropriate (latest) kexec/kdump (-mm) kernel
-   patchset and apply it to the vanilla kernel tree.
+2) Download and build the appropriate (2.6.13-rc1 onwards) vanilla kernel.
 
    Two kernels need to be built in order to get this feature working.
 
@@ -84,15 +83,16 @@ SETUP
 
 4) Load the second kernel to be booted using:
 
-   kexec -p <second-kernel> --crash-dump --args-linux --append="root=<root-dev>
-   init 1 irqpoll"
+   kexec -p <second-kernel> --args-linux --elf32-core-headers
+   --append="root=<root-dev> init 1 irqpoll"
 
    Note: i) <second-kernel> has to be a vmlinux image. bzImage will not work,
            as of now.
-       ii) By default ELF headers are stored in ELF32 format (for i386). This
-           is sufficient to represent the physical memory up to 4GB. To store
-           headers in ELF64 format, specifiy "--elf64-core-headers" on the
-           kexec command line additionally.
+       ii) By default ELF headers are stored in ELF64 format. Option
+           --elf32-core-headers forces generation of ELF32 headers. gdb can
+           not open ELF64 headers on 32 bit systems. So creating ELF32
+           headers can come handy for users who have got non-PAE systems and
+           hence have memory less than 4GB.
        iii) Specify "irqpoll" as command line parameter. This reduces driver
             initialization failures in second kernel due to shared interrupts.
 
index f97841478459037c5627814f345c30c3d3ed6d21..5df44dc894e594a7ef6344a05a0439fe7ebcce98 100644 (file)
@@ -57,7 +57,7 @@ With BK, you can just get it from
 
 and DaveJ has tar-balls at
 
-       http://www.codemonkey.org.uk/projects/bitkeeper/sparse/
+       http://www.codemonkey.org.uk/projects/git-snapshots/sparse/
 
 
 Once you have it, just do
index 62a12a08e2ac5c431ecb50e9358296a9ff76c0f3..ec785f9f15a3168e5d95f230b19da743e7a588db 100644 (file)
@@ -126,10 +126,12 @@ card=124 - AverMedia AverTV DVB-T 761
 card=125 - MATRIX Vision Sigma-SQ
 card=126 - MATRIX Vision Sigma-SLC
 card=127 - APAC Viewcomp 878(AMAX)
-card=128 - DVICO FusionHDTV DVB-T Lite
+card=128 - DViCO FusionHDTV DVB-T Lite
 card=129 - V-Gear MyVCD
 card=130 - Super TV Tuner
 card=131 - Tibet Systems 'Progress DVR' CS16
 card=132 - Kodicom 4400R (master)
 card=133 - Kodicom 4400R (slave)
 card=134 - Adlink RTV24
+card=135 - DViCO FusionHDTV 5 Lite
+card=136 - Acorp Y878F
index 1b5a3a9ffbe2bbf7913a934888e23c034260ff5c..dc57225f39be5b973f74fe0e7f2b451bdc1c7821 100644 (file)
@@ -62,3 +62,6 @@
  61 -> Philips TOUGH DVB-T reference design     [1131:2004]
  62 -> Compro VideoMate TV Gold+II
  63 -> Kworld Xpert TV PVR7134
+ 64 -> FlyTV mini Asus Digimatrix               [1043:0210,1043:0210]
+ 65 -> V-Stream Studio TV Terminator
+ 66 -> Yuan TUN-900 (saa7135)
index f3302e1b1b9c4a31836612917336af57094befcd..f5876be658a64f3724df1ef71cc41b5786f15a38 100644 (file)
@@ -64,3 +64,4 @@ tuner=62 - Philips TEA5767HN FM Radio
 tuner=63 - Philips FMD1216ME MK3 Hybrid Tuner
 tuner=64 - LG TDVS-H062F/TUA6034
 tuner=65 - Ymec TVF66T5-B/DFF
+tuner=66 - LG NTSC (TALN mini series)
diff --git a/Kbuild b/Kbuild
new file mode 100644 (file)
index 0000000..1880e6f
--- /dev/null
+++ b/Kbuild
@@ -0,0 +1,48 @@
+#
+# Kbuild for top-level directory of the kernel
+# This file takes care of the following:
+# 1) Generate asm-offsets.h
+
+#####
+# 1) Generate asm-offsets.h 
+#
+
+offsets-file := include/asm-$(ARCH)/asm-offsets.h
+
+always  := $(offsets-file)
+targets := $(offsets-file)
+targets += arch/$(ARCH)/kernel/asm-offsets.s
+
+# Default sed regexp - multiline due to syntax constraints
+define sed-y
+       "/^->/{s:^->\([^ ]*\) [\$$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:; s:->::; p;}"
+endef
+# Override default regexp for specific architectures
+sed-$(CONFIG_MIPS) := "/^@@@/s///p"
+
+quiet_cmd_offsets = GEN     $@
+define cmd_offsets
+       cat $< | \
+       (set -e; \
+        echo "#ifndef __ASM_OFFSETS_H__"; \
+        echo "#define __ASM_OFFSETS_H__"; \
+        echo "/*"; \
+        echo " * DO NOT MODIFY."; \
+        echo " *"; \
+        echo " * This file was generated by $(srctree)/Kbuild"; \
+        echo " *"; \
+        echo " */"; \
+        echo ""; \
+        sed -ne $(sed-y); \
+        echo ""; \
+        echo "#endif" ) > $@
+endef
+
+# We use internal kbuild rules to avoid the "is up to date" message from make
+arch/$(ARCH)/kernel/asm-offsets.s: arch/$(ARCH)/kernel/asm-offsets.c FORCE
+       $(Q)mkdir -p $(dir $@)
+       $(call if_changed_dep,cc_s_c)
+
+$(srctree)/$(offsets-file): arch/$(ARCH)/kernel/asm-offsets.s Kbuild
+       $(call cmd,offsets)
+
index eaa46594f0211a4abdb420e9abb758c2ad95f26b..f038dca34ee826b543db0d54f40623e954e5bf72 100644 (file)
@@ -626,6 +626,12 @@ M: rmk@arm.linux.org.uk
 W:     http://www.arm.linux.org.uk/
 S:     Maintained
 
+CYBLAFB FRAMEBUFFER DRIVER
+P:     Knut Petersen
+M:     Knut_Petersen@t-online.de
+L:     linux-fbdev-devel@lists.sourceforge.net
+S:     Maintained
+
 CYCLADES 2X SYNC CARD DRIVER
 P:     Arnaldo Carvalho de Melo
 M:     acme@conectiva.com.br
@@ -925,6 +931,13 @@ L: linux-tape@vger.kernel.org
 W:     http://sourceforge.net/projects/ftape
 S:     Orphan
 
+FUSE: FILESYSTEM IN USERSPACE
+P:     Miklos Szeredi
+M:     miklos@szeredi.hu
+L:     fuse-devel@lists.sourceforge.net
+W:     http://fuse.sourceforge.net/
+S:     Maintained
+
 FUTURE DOMAIN TMC-16x0 SCSI DRIVER (16-bit)
 P:     Rik Faith
 M:     faith@cs.unc.edu
@@ -2684,6 +2697,17 @@ L:       rio500-users@lists.sourceforge.net
 W:     http://rio500.sourceforge.net
 S:     Maintained
 
+V9FS FILE SYSTEM
+P:      Eric Van Hensbergen
+M:      ericvh@gmail.com
+P:      Ron Minnich
+M:      rminnich@lanl.gov
+P:      Latchesar Ionkov
+M:      lucho@ionkov.net
+L:      v9fs-developer@lists.sourceforge.net
+W:      http://v9fs.sf.net
+S:      Maintained
+
 VIDEO FOR LINUX
 P:     Mauro Carvalho Chehab
 M:     mchehab@brturbo.com.br
index 63e5c9f0bc7ad9776a4f9a33e07600b0085c5672..2402430c87e663d99841f84980039c999af3d4d6 100644 (file)
--- a/Makefile
+++ b/Makefile
@@ -776,14 +776,14 @@ $(vmlinux-dirs): prepare-all scripts
 # A multi level approach is used. prepare1 is updated first, then prepare0.
 # prepare-all is the collection point for the prepare targets.
 
-.PHONY: prepare-all prepare prepare0 prepare1 prepare2
+.PHONY: prepare-all prepare prepare0 prepare1 prepare2 prepare3
 
-# prepare2 is used to check if we are building in a separate output directory,
+# prepare3 is used to check if we are building in a separate output directory,
 # and if so do:
 # 1) Check that make has not been executed in the kernel src $(srctree)
 # 2) Create the include2 directory, used for the second asm symlink
 
-prepare2:
+prepare3:
 ifneq ($(KBUILD_SRC),)
        @echo '  Using $(srctree) as source for kernel'
        $(Q)if [ -f $(srctree)/.config ]; then \
@@ -795,18 +795,21 @@ ifneq ($(KBUILD_SRC),)
        $(Q)ln -fsn $(srctree)/include/asm-$(ARCH) include2/asm
 endif
 
-# prepare1 creates a makefile if using a separate output directory
-prepare1: prepare2 outputmakefile
+# prepare2 creates a makefile if using a separate output directory
+prepare2: prepare3 outputmakefile
 
-prepare0: prepare1 include/linux/version.h include/asm \
+prepare1: prepare2 include/linux/version.h include/asm \
                    include/config/MARKER
 ifneq ($(KBUILD_MODULES),)
        $(Q)rm -rf $(MODVERDIR)
        $(Q)mkdir -p $(MODVERDIR)
 endif
 
+prepare0: prepare prepare1 FORCE
+       $(Q)$(MAKE) $(build)=$(srctree)
+
 # All the preparing..
-prepare-all: prepare0 prepare
+prepare-all: prepare0
 
 #      Leave this as default for preprocessing vmlinux.lds.S, which is now
 #      done in arch/$(ARCH)/kernel/Makefile
@@ -949,26 +952,6 @@ modules modules_install: FORCE
 
 endif # CONFIG_MODULES
 
-# Generate asm-offsets.h 
-# ---------------------------------------------------------------------------
-
-define filechk_gen-asm-offsets
-       (set -e; \
-        echo "#ifndef __ASM_OFFSETS_H__"; \
-        echo "#define __ASM_OFFSETS_H__"; \
-        echo "/*"; \
-        echo " * DO NOT MODIFY."; \
-        echo " *"; \
-        echo " * This file was generated by arch/$(ARCH)/Makefile"; \
-        echo " *"; \
-        echo " */"; \
-        echo ""; \
-        sed -ne "/^->/{s:^->\([^ ]*\) [\$$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:; s:->::; p;}"; \
-        echo ""; \
-        echo "#endif" )
-endef
-
-
 ###
 # Cleaning is done on three levels.
 # make clean     Delete most generated files
@@ -991,7 +974,7 @@ MRPROPER_FILES += .config .config.old include/asm .version \
 #
 clean: rm-dirs  := $(CLEAN_DIRS)
 clean: rm-files := $(CLEAN_FILES)
-clean-dirs      := $(addprefix _clean_,$(vmlinux-alldirs))
+clean-dirs      := $(addprefix _clean_,$(srctree) $(vmlinux-alldirs))
 
 .PHONY: $(clean-dirs) clean archclean
 $(clean-dirs):
index 22ebfb2be0e4c655a5e764eb0c99598b4035cb37..1b704ee54bf3ad5210aab22c6f36d372aadc19e6 100644 (file)
@@ -108,20 +108,9 @@ $(boot)/vmlinux.gz: vmlinux
 bootimage bootpfile bootpzfile: vmlinux
        $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
 
-
-prepare: include/asm-$(ARCH)/asm_offsets.h
-
-arch/$(ARCH)/kernel/asm-offsets.s: include/asm include/linux/version.h \
-                                  include/config/MARKER
-
-include/asm-$(ARCH)/asm_offsets.h: arch/$(ARCH)/kernel/asm-offsets.s
-       $(call filechk,gen-asm-offsets)
-
 archclean:
        $(Q)$(MAKE) $(clean)=$(boot)
 
-CLEAN_FILES += include/asm-$(ARCH)/asm_offsets.h
-
 define archhelp
   echo '* boot         - Compressed kernel image (arch/alpha/boot/vmlinux.gz)'
   echo '  bootimage    - SRM bootable image (arch/alpha/boot/bootimage)'
index f0927ee53f29c73b5491e692117e5dec2ee88d97..76cc0cb5fc2e429ebe0a98026271bbff7a6225f9 100644 (file)
@@ -5,7 +5,7 @@
  */
 
 #include <linux/config.h>
-#include <asm/asm_offsets.h>
+#include <asm/asm-offsets.h>
 #include <asm/thread_info.h>
 #include <asm/pal.h>
 #include <asm/errno.h>
index 4ca2e404708a46cd8bc4681a57ce1c9f2db7f964..0905721fcbcaba4f89425b8d22d0281426e78b81 100644 (file)
@@ -9,7 +9,7 @@
 
 #include <linux/config.h>
 #include <asm/system.h>
-#include <asm/asm_offsets.h>
+#include <asm/asm-offsets.h>
 
 .globl swapper_pg_dir
 .globl _stext
index fc271e316a388f774150777f8f35f955484d8151..aac6d4b22f7a23dd81a2f954fb380778708a0cf9 100644 (file)
@@ -47,7 +47,7 @@ module_free(struct module *mod, void *module_region)
 
 struct got_entry {
        struct got_entry *next;
-       Elf64_Addr r_offset;
+       Elf64_Sxword r_addend;
        int got_offset;
 };
 
@@ -57,14 +57,14 @@ process_reloc_for_got(Elf64_Rela *rela,
 {
        unsigned long r_sym = ELF64_R_SYM (rela->r_info);
        unsigned long r_type = ELF64_R_TYPE (rela->r_info);
-       Elf64_Addr r_offset = rela->r_offset;
+       Elf64_Sxword r_addend = rela->r_addend;
        struct got_entry *g;
 
        if (r_type != R_ALPHA_LITERAL)
                return;
 
        for (g = chains + r_sym; g ; g = g->next)
-               if (g->r_offset == r_offset) {
+               if (g->r_addend == r_addend) {
                        if (g->got_offset == 0) {
                                g->got_offset = *poffset;
                                *poffset += 8;
@@ -74,7 +74,7 @@ process_reloc_for_got(Elf64_Rela *rela,
 
        g = kmalloc (sizeof (*g), GFP_KERNEL);
        g->next = chains[r_sym].next;
-       g->r_offset = r_offset;
+       g->r_addend = r_addend;
        g->got_offset = *poffset;
        *poffset += 8;
        chains[r_sym].next = g;
index 167fd89f8707aeb1b0ad59190e9fa352718d5900..2b034182a0ca82c6ee33c4deeb0f59af3f99d825 100644 (file)
@@ -974,6 +974,7 @@ osf_select(int n, fd_set __user *inp, fd_set __user *outp, fd_set __user *exp,
        size_t size;
        long timeout;
        int ret = -EINVAL;
+       struct fdtable *fdt;
 
        timeout = MAX_SCHEDULE_TIMEOUT;
        if (tvp) {
@@ -995,7 +996,8 @@ osf_select(int n, fd_set __user *inp, fd_set __user *outp, fd_set __user *exp,
                }
        }
 
-       if (n < 0 || n > current->files->max_fdset)
+       fdt = files_fdtable(current->files);
+       if (n < 0 || n > fdt->max_fdset)
                goto out_nofds;
 
        /*
index cc5ce3a5fcad2dc10d918e60f749ea1127dcd58d..3c1f3e6522e5d59aa9c2b290b7095b02c90108f5 100644 (file)
@@ -5,7 +5,7 @@
  * Verify that we have not overflowed the stack.  Oops if we have.
  */
 
-#include <asm/asm_offsets.h>
+#include <asm/asm-offsets.h>
 
        .text
        .set noat
index e09f2ae1e09e36b8639c241141d5fa93df060464..e9f6a9dcf2b7c31bc947127422bf0fd7d9462072 100644 (file)
@@ -6,7 +6,7 @@
  * uninitialized local variables in the act.
  */
 
-#include <asm/asm_offsets.h>
+#include <asm/asm-offsets.h>
 
        .text
        .set noat
index 67f1453ade05e9afc085a7b0fb93e518dd053af8..e625ac66f49b2fc3cd54dbdec41e9c340ab8e911 100644 (file)
@@ -178,7 +178,7 @@ endif
 prepare: maketools include/asm-arm/.arch
 
 .PHONY: maketools FORCE
-maketools: include/asm-arm/constants.h include/linux/version.h FORCE
+maketools: include/linux/version.h FORCE
        $(Q)$(MAKE) $(build)=arch/arm/tools include/asm-arm/mach-types.h
 
 # Convert bzImage to zImage
@@ -190,7 +190,7 @@ zImage Image xipImage bootpImage uImage: vmlinux
 zinstall install: vmlinux
        $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $@
 
-CLEAN_FILES += include/asm-arm/constants.h* include/asm-arm/mach-types.h \
+CLEAN_FILES += include/asm-arm/mach-types.h \
               include/asm-arm/arch include/asm-arm/.arch
 
 # We use MRPROPER_FILES and CLEAN_FILES now
@@ -201,11 +201,6 @@ archclean:
 bp:;   $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/bootpImage
 i zi:; $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $@
 
-arch/$(ARCH)/kernel/asm-offsets.s: include/asm include/linux/version.h \
-                                  include/asm-arm/.arch
-
-include/asm-$(ARCH)/constants.h: arch/$(ARCH)/kernel/asm-offsets.s
-       $(call filechk,gen-asm-offsets)
 
 define archhelp
   echo  '* zImage        - Compressed kernel image (arch/$(ARCH)/boot/zImage)'
index afef21273963a6599fde7330e555f52f302faf60..648cfff93138bdc1df9e025efef31dbc1211a821 100644 (file)
@@ -3,7 +3,7 @@
 #include <linux/linkage.h>
 
 #include <asm/assembler.h>
-#include <asm/constants.h>
+#include <asm/asm-offsets.h>
 #include <asm/errno.h>
 #include <asm/thread_info.h>
 
index 1155cf07c8710e7be4b55d92f144ffcdaeb5d10f..53962635134862263fb2719b3293249dc53187cc 100644 (file)
@@ -20,7 +20,7 @@
 #include <asm/mach-types.h>
 #include <asm/procinfo.h>
 #include <asm/ptrace.h>
-#include <asm/constants.h>
+#include <asm/asm-offsets.h>
 #include <asm/thread_info.h>
 #include <asm/system.h>
 
index 8f74e24536ba7b394c0b3b4786903e8839fb36b3..24c7b0477a09612ac65af3bc614812f5b4b7b276 100644 (file)
@@ -17,7 +17,7 @@
 #include <linux/linkage.h>
 #include <asm/ptrace.h>
 #include <asm/thread_info.h>
-#include <asm/constants.h>
+#include <asm/asm-offsets.h>
 
 #define MMX_WR0                        (0x00)
 #define MMX_WR1                        (0x08)
index 4c38abdbe497b57d4cc460a9a55055d9df394b8b..68117968482bbe5f4c021732ba00624ee321ec54 100644 (file)
@@ -11,7 +11,7 @@
  */
 #include <linux/linkage.h>
 #include <asm/assembler.h>
-#include <asm/constants.h>
+#include <asm/asm-offsets.h>
 
 #define COPY_COUNT (PAGE_SZ/64 PLD( -1 ))
 
index 46a2dc962e9dd6f6420d120da6cfa988d1aecc21..333bca292de93a5b0eec17405207089395dbf88f 100644 (file)
@@ -13,7 +13,7 @@
 #include <linux/linkage.h>
 #include <asm/assembler.h>
 #include <asm/errno.h>
-#include <asm/constants.h>
+#include <asm/asm-offsets.h>
 
                .text
 
index 64aa6f4fe5e4a4dc3c888efb3a27e9a4275b0285..d204018070a49bde08c2c32b610c8b9edef37b5b 100644 (file)
@@ -26,7 +26,7 @@
  * Note that ADDR_LIMIT is either 0 or 0xc0000000.
  * Note also that it is intended that __get_user_bad is not global.
  */
-#include <asm/constants.h>
+#include <asm/asm-offsets.h>
 #include <asm/thread_info.h>
 #include <asm/errno.h>
 
index b09398d95aac7cef468202ce0745597e7b505f7e..4593e9c07f0530b051559afa179189020247bf89 100644 (file)
@@ -26,7 +26,7 @@
  * Note that ADDR_LIMIT is either 0 or 0xc0000000
  * Note also that it is intended that __put_user_bad is not global.
  */
-#include <asm/constants.h>
+#include <asm/asm-offsets.h>
 #include <asm/thread_info.h>
 #include <asm/errno.h>
 
index 8ccffba0018fa5f1ef5d607c0be447ffc1dacd4c..366a9bde3d8be08880231795926d834839d35ddc 100644 (file)
@@ -22,7 +22,7 @@
 #include <asm/arch/corgi.h>
 #include <asm/arch/pxa-regs.h>
 
-static spinlock_t corgi_ssp_lock = SPIN_LOCK_UNLOCKED;
+static DEFINE_SPINLOCK(corgi_ssp_lock);
 static struct ssp_dev corgi_ssp_dev;
 static struct ssp_state corgi_ssp_state;
 
index 4664bd11adc1eb45931431ea38d895c819936b8a..0077937a7ab865f67faaca5ff684d2ca3cc0db6f 100644 (file)
@@ -29,7 +29,7 @@
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
 #include <asm/mach/irq.h>
-
+#include <asm/arch/fb.h>
 #include <asm/hardware.h>
 #include <asm/io.h>
 #include <asm/irq.h>
@@ -103,6 +103,15 @@ struct platform_device s3c_device_lcd = {
 
 EXPORT_SYMBOL(s3c_device_lcd);
 
+static struct s3c2410fb_mach_info s3c2410fb_info;
+
+void __init set_s3c2410fb_info(struct s3c2410fb_mach_info *hard_s3c2410fb_info)
+{
+       memcpy(&s3c2410fb_info,hard_s3c2410fb_info,sizeof(struct s3c2410fb_mach_info));
+       s3c_device_lcd.dev.platform_data = &s3c2410fb_info;
+}
+EXPORT_SYMBOL(set_s3c2410fb_info);
+
 /* NAND Controller */
 
 static struct resource s3c_nand_resource[] = {
index ea4fb1a97a50aa1fbcba1d883918808eb601d218..6ff1889fbd21facb8b13b3bcf1a9eff3685509fe 100644 (file)
@@ -45,6 +45,9 @@
 
 //#include <asm/debug-ll.h>
 #include <asm/arch/regs-serial.h>
+#include <asm/arch/regs-lcd.h>
+
+#include <asm/arch/fb.h>
 
 #include <linux/serial_core.h>
 
@@ -88,6 +91,48 @@ static struct s3c2410_uartcfg h1940_uartcfgs[] = {
 
 
 
+/**
+ * Set lcd on or off
+ **/
+static struct s3c2410fb_mach_info h1940_lcdcfg __initdata = {
+       .fixed_syncs=           1,
+       .regs={
+               .lcdcon1=       S3C2410_LCDCON1_TFT16BPP | \
+                               S3C2410_LCDCON1_TFT | \
+                               S3C2410_LCDCON1_CLKVAL(0x0C),
+
+               .lcdcon2=       S3C2410_LCDCON2_VBPD(7) | \
+                               S3C2410_LCDCON2_LINEVAL(319) | \
+                               S3C2410_LCDCON2_VFPD(6) | \
+                               S3C2410_LCDCON2_VSPW(0),
+
+               .lcdcon3=       S3C2410_LCDCON3_HBPD(19) | \
+                               S3C2410_LCDCON3_HOZVAL(239) | \
+                               S3C2410_LCDCON3_HFPD(7),
+
+               .lcdcon4=       S3C2410_LCDCON4_MVAL(0) | \
+                               S3C2410_LCDCON4_HSPW(3),
+