X-Git-Url: http://git.onelab.eu/?a=blobdiff_plain;f=linux-2.6-590-trellis-mm1-netns.patch;h=bf6b6a90e12c39c54bfd7d08cdc423ca071dc393;hb=refs%2Fheads%2Ftrellis-sapan;hp=22a0b86943a17c9bbdd28d34c3ff338048c74d25;hpb=84fb14b85ed409099361e6cc083f70d026a19eca;p=linux-2.6.git
diff --git a/linux-2.6-590-trellis-mm1-netns.patch b/linux-2.6-590-trellis-mm1-netns.patch
index 22a0b8694..bf6b6a90e 100644
--- a/linux-2.6-590-trellis-mm1-netns.patch
+++ b/linux-2.6-590-trellis-mm1-netns.patch
@@ -1,12229 +1,8457 @@
-diff -Nurb linux-2.6.22-590/.config.orig linux-2.6.22-570/.config.orig
---- linux-2.6.22-590/.config.orig 2008-01-23 19:16:18.000000000 -0500
-+++ linux-2.6.22-570/.config.orig 1969-12-31 19:00:00.000000000 -0500
-@@ -1,1693 +0,0 @@
--#
--# Automatically generated make config: don't edit
--# Linux kernel version: 2.6.22-prep
--# Fri Dec 21 15:54:46 2007
--#
--CONFIG_X86_32=y
--CONFIG_GENERIC_TIME=y
--CONFIG_CLOCKSOURCE_WATCHDOG=y
--CONFIG_GENERIC_CLOCKEVENTS=y
--CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
--CONFIG_LOCKDEP_SUPPORT=y
--CONFIG_STACKTRACE_SUPPORT=y
--CONFIG_SEMAPHORE_SLEEPERS=y
--CONFIG_X86=y
--CONFIG_MMU=y
--CONFIG_ZONE_DMA=y
--CONFIG_QUICKLIST=y
--CONFIG_GENERIC_ISA_DMA=y
--CONFIG_GENERIC_IOMAP=y
--CONFIG_GENERIC_BUG=y
--CONFIG_GENERIC_HWEIGHT=y
--CONFIG_ARCH_MAY_HAVE_PC_FDC=y
--CONFIG_DMI=y
--CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
--
--#
--# Code maturity level options
--#
--CONFIG_EXPERIMENTAL=y
--CONFIG_LOCK_KERNEL=y
--CONFIG_INIT_ENV_ARG_LIMIT=32
--
--#
--# General setup
--#
--CONFIG_LOCALVERSION=""
--CONFIG_LOCALVERSION_AUTO=y
--CONFIG_SWAP=y
--CONFIG_SYSVIPC=y
--CONFIG_SYSVIPC_SYSCTL=y
--CONFIG_POSIX_MQUEUE=y
--# CONFIG_BSD_PROCESS_ACCT is not set
--# CONFIG_TASKSTATS is not set
--# CONFIG_USER_NS is not set
--# CONFIG_AUDIT is not set
--CONFIG_IKCONFIG=y
--CONFIG_IKCONFIG_PROC=y
--CONFIG_LOG_BUF_SHIFT=18
--CONFIG_OOM_PANIC=y
--# CONFIG_CONTAINER_DEBUG is not set
--# CONFIG_CPUSETS is not set
--CONFIG_SYSFS_DEPRECATED=y
--# CONFIG_CONTAINER_CPUACCT is not set
--# CONFIG_CONTAINER_NS is not set
--# CONFIG_RELAY is not set
--CONFIG_BLK_DEV_INITRD=y
--CONFIG_INITRAMFS_SOURCE=""
--CONFIG_CC_OPTIMIZE_FOR_SIZE=y
--CONFIG_SYSCTL=y
--# CONFIG_EMBEDDED is not set
--CONFIG_UID16=y
--CONFIG_SYSCTL_SYSCALL=y
--CONFIG_KALLSYMS=y
--CONFIG_KALLSYMS_ALL=y
--# CONFIG_KALLSYMS_EXTRA_PASS is not set
--CONFIG_HOTPLUG=y
--CONFIG_PRINTK=y
--CONFIG_BUG=y
--CONFIG_ELF_CORE=y
--CONFIG_BASE_FULL=y
--CONFIG_FUTEX=y
--CONFIG_ANON_INODES=y
--CONFIG_EPOLL=y
--CONFIG_SIGNALFD=y
--CONFIG_EVENTFD=y
--CONFIG_SHMEM=y
--CONFIG_VM_EVENT_COUNTERS=y
--CONFIG_SLAB=y
--# CONFIG_SLUB is not set
--# CONFIG_SLOB is not set
--CONFIG_PROC_SMAPS=y
--CONFIG_PROC_CLEAR_REFS=y
--CONFIG_PROC_PAGEMAP=y
--CONFIG_RT_MUTEXES=y
--# CONFIG_TINY_SHMEM is not set
--CONFIG_BASE_SMALL=0
--CONFIG_PAGE_GROUP_BY_MOBILITY=y
--
--#
--# Loadable module support
--#
--CONFIG_MODULES=y
--CONFIG_MODULE_UNLOAD=y
--CONFIG_MODULE_FORCE_UNLOAD=y
--# CONFIG_MODVERSIONS is not set
--# CONFIG_MODULE_SRCVERSION_ALL is not set
--# CONFIG_KMOD is not set
--CONFIG_STOP_MACHINE=y
--
--#
--# Block layer
--#
--CONFIG_BLOCK=y
--CONFIG_LBD=y
--# CONFIG_BLK_DEV_IO_TRACE is not set
--# CONFIG_LSF is not set
--
--#
--# IO Schedulers
--#
--CONFIG_IOSCHED_NOOP=y
--CONFIG_IOSCHED_AS=y
--CONFIG_IOSCHED_DEADLINE=y
--CONFIG_IOSCHED_CFQ=y
--CONFIG_DEFAULT_AS=y
--# CONFIG_DEFAULT_DEADLINE is not set
--# CONFIG_DEFAULT_CFQ is not set
--# CONFIG_DEFAULT_NOOP is not set
--CONFIG_DEFAULT_IOSCHED="anticipatory"
--
--#
--# Processor type and features
--#
--# CONFIG_TICK_ONESHOT is not set
--# CONFIG_NO_HZ is not set
--# CONFIG_HIGH_RES_TIMERS is not set
--CONFIG_SMP=y
--# CONFIG_X86_PC is not set
--# CONFIG_X86_ELAN is not set
--# CONFIG_X86_VOYAGER is not set
--# CONFIG_X86_NUMAQ is not set
--# CONFIG_X86_SUMMIT is not set
--# CONFIG_X86_BIGSMP is not set
--# CONFIG_X86_VISWS is not set
--CONFIG_X86_GENERICARCH=y
--# CONFIG_X86_ES7000 is not set
--# CONFIG_PARAVIRT is not set
--CONFIG_X86_CYCLONE_TIMER=y
--# CONFIG_M386 is not set
--# CONFIG_M486 is not set
--# CONFIG_M586 is not set
--# CONFIG_M586TSC is not set
--# CONFIG_M586MMX is not set
--# CONFIG_M686 is not set
--# CONFIG_MPENTIUMII is not set
--CONFIG_MPENTIUMIII=y
--# CONFIG_MPENTIUMM is not set
--# CONFIG_MCORE2 is not set
--# CONFIG_MPENTIUM4 is not set
--# CONFIG_MK6 is not set
--# CONFIG_MK7 is not set
--# CONFIG_MK8 is not set
--# CONFIG_MCRUSOE is not set
--# CONFIG_MEFFICEON is not set
--# CONFIG_MWINCHIPC6 is not set
--# CONFIG_MWINCHIP2 is not set
--# CONFIG_MWINCHIP3D is not set
--# CONFIG_MGEODEGX1 is not set
--# CONFIG_MGEODE_LX is not set
--# CONFIG_MCYRIXIII is not set
--# CONFIG_MVIAC3_2 is not set
--# CONFIG_MVIAC7 is not set
--CONFIG_X86_GENERIC=y
--CONFIG_X86_CMPXCHG=y
--CONFIG_X86_L1_CACHE_SHIFT=7
--CONFIG_X86_XADD=y
--CONFIG_RWSEM_XCHGADD_ALGORITHM=y
--# CONFIG_ARCH_HAS_ILOG2_U32 is not set
--# CONFIG_ARCH_HAS_ILOG2_U64 is not set
--CONFIG_GENERIC_CALIBRATE_DELAY=y
--CONFIG_X86_WP_WORKS_OK=y
--CONFIG_X86_INVLPG=y
--CONFIG_X86_BSWAP=y
--CONFIG_X86_POPAD_OK=y
--CONFIG_X86_GOOD_APIC=y
--CONFIG_X86_INTEL_USERCOPY=y
--CONFIG_X86_USE_PPRO_CHECKSUM=y
--CONFIG_X86_TSC=y
--CONFIG_X86_CMOV=y
--CONFIG_X86_MINIMUM_CPU_MODEL=4
--CONFIG_HPET_TIMER=y
--CONFIG_HPET_EMULATE_RTC=y
--CONFIG_NR_CPUS=32
--CONFIG_SCHED_SMT=y
--CONFIG_SCHED_MC=y
--# CONFIG_PREEMPT_NONE is not set
--CONFIG_PREEMPT_VOLUNTARY=y
--# CONFIG_PREEMPT is not set
--CONFIG_PREEMPT_BKL=y
--CONFIG_X86_LOCAL_APIC=y
--CONFIG_X86_IO_APIC=y
--CONFIG_X86_MCE=y
--CONFIG_X86_MCE_NONFATAL=y
--CONFIG_X86_MCE_P4THERMAL=y
--CONFIG_VM86=y
--# CONFIG_TOSHIBA is not set
--# CONFIG_I8K is not set
--# CONFIG_X86_REBOOTFIXUPS is not set
--CONFIG_MICROCODE=y
--CONFIG_MICROCODE_OLD_INTERFACE=y
--CONFIG_X86_MSR=y
--CONFIG_X86_CPUID=y
--
--#
--# Firmware Drivers
--#
--# CONFIG_EDD is not set
--# CONFIG_DELL_RBU is not set
--# CONFIG_DCDBAS is not set
--# CONFIG_NOHIGHMEM is not set
--CONFIG_HIGHMEM4G=y
--# CONFIG_HIGHMEM64G is not set
--CONFIG_PAGE_OFFSET=0xC0000000
--CONFIG_HIGHMEM=y
--CONFIG_ARCH_POPULATES_NODE_MAP=y
--CONFIG_SELECT_MEMORY_MODEL=y
--CONFIG_FLATMEM_MANUAL=y
--# CONFIG_DISCONTIGMEM_MANUAL is not set
--# CONFIG_SPARSEMEM_MANUAL is not set
--CONFIG_FLATMEM=y
--CONFIG_FLAT_NODE_MEM_MAP=y
--# CONFIG_SPARSEMEM_STATIC is not set
--CONFIG_SPLIT_PTLOCK_CPUS=4
--CONFIG_RESOURCES_64BIT=y
--CONFIG_ZONE_DMA_FLAG=1
--CONFIG_NR_QUICK=1
--# CONFIG_HIGHPTE is not set
--# CONFIG_MATH_EMULATION is not set
--CONFIG_MTRR=y
--# CONFIG_EFI is not set
--# CONFIG_IRQBALANCE is not set
--CONFIG_SECCOMP=y
--# CONFIG_HZ_100 is not set
--CONFIG_HZ_250=y
--# CONFIG_HZ_300 is not set
--# CONFIG_HZ_1000 is not set
--CONFIG_HZ=250
--CONFIG_KEXEC=y
--# CONFIG_CRASH_DUMP is not set
--CONFIG_PHYSICAL_START=0x100000
--# CONFIG_RELOCATABLE is not set
--CONFIG_PHYSICAL_ALIGN=0x100000
--# CONFIG_HOTPLUG_CPU is not set
--CONFIG_COMPAT_VDSO=y
--CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
--
--#
--# Power management options (ACPI, APM)
--#
--CONFIG_PM=y
--CONFIG_PM_LEGACY=y
--# CONFIG_PM_DEBUG is not set
--CONFIG_PM_SYSFS_DEPRECATED=y
--
--#
--# ACPI (Advanced Configuration and Power Interface) Support
--#
--CONFIG_ACPI=y
--CONFIG_ACPI_PROCFS=y
--CONFIG_ACPI_AC=y
--CONFIG_ACPI_BATTERY=y
--CONFIG_ACPI_BUTTON=y
--CONFIG_ACPI_FAN=y
--# CONFIG_ACPI_DOCK is not set
--CONFIG_ACPI_PROCESSOR=y
--CONFIG_ACPI_THERMAL=y
--# CONFIG_ACPI_ASUS is not set
--# CONFIG_ACPI_TOSHIBA is not set
--CONFIG_ACPI_BLACKLIST_YEAR=2001
--CONFIG_ACPI_DEBUG=y
--# CONFIG_ACPI_DEBUG_FUNC_TRACE is not set
--CONFIG_ACPI_EC=y
--CONFIG_ACPI_POWER=y
--CONFIG_ACPI_SYSTEM=y
--CONFIG_X86_PM_TIMER=y
--# CONFIG_ACPI_CONTAINER is not set
--# CONFIG_ACPI_SBS is not set
--# CONFIG_APM is not set
--
--#
--# CPU Frequency scaling
--#
--CONFIG_CPU_FREQ=y
--CONFIG_CPU_FREQ_TABLE=y
--CONFIG_CPU_FREQ_DEBUG=y
--CONFIG_CPU_FREQ_STAT=y
--# CONFIG_CPU_FREQ_STAT_DETAILS is not set
--CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
--# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
--CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
--# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set
--CONFIG_CPU_FREQ_GOV_USERSPACE=y
--CONFIG_CPU_FREQ_GOV_ONDEMAND=y
--# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set
--
--#
--# CPUFreq processor drivers
--#
--CONFIG_X86_ACPI_CPUFREQ=y
--# CONFIG_X86_POWERNOW_K6 is not set
--# CONFIG_X86_POWERNOW_K7 is not set
--CONFIG_X86_POWERNOW_K8=y
--CONFIG_X86_POWERNOW_K8_ACPI=y
--# CONFIG_X86_GX_SUSPMOD is not set
--# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
--# CONFIG_X86_SPEEDSTEP_ICH is not set
--# CONFIG_X86_SPEEDSTEP_SMI is not set
--# CONFIG_X86_P4_CLOCKMOD is not set
--# CONFIG_X86_CPUFREQ_NFORCE2 is not set
--# CONFIG_X86_LONGRUN is not set
--# CONFIG_X86_LONGHAUL is not set
--# CONFIG_X86_E_POWERSAVER is not set
--
--#
--# shared options
--#
--CONFIG_X86_ACPI_CPUFREQ_PROC_INTF=y
--# CONFIG_X86_SPEEDSTEP_LIB is not set
--
--#
--# CPU idle PM support
--#
--# CONFIG_CPU_IDLE is not set
--
--#
--# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
--#
--CONFIG_PCI=y
--# CONFIG_PCI_GOBIOS is not set
--# CONFIG_PCI_GOMMCONFIG is not set
--# CONFIG_PCI_GODIRECT is not set
--CONFIG_PCI_GOANY=y
--CONFIG_PCI_BIOS=y
--CONFIG_PCI_DIRECT=y
--CONFIG_PCI_MMCONFIG=y
--# CONFIG_PCIEPORTBUS is not set
--CONFIG_ARCH_SUPPORTS_MSI=y
--CONFIG_PCI_MSI=y
--# CONFIG_PCI_DEBUG is not set
--# CONFIG_HT_IRQ is not set
--CONFIG_ISA_DMA_API=y
--# CONFIG_ISA is not set
--# CONFIG_MCA is not set
--# CONFIG_SCx200 is not set
--
--#
--# PCCARD (PCMCIA/CardBus) support
--#
--# CONFIG_PCCARD is not set
--# CONFIG_HOTPLUG_PCI is not set
--
--#
--# Executable file formats
--#
--CONFIG_BINFMT_ELF=y
--# CONFIG_BINFMT_AOUT is not set
--# CONFIG_BINFMT_MISC is not set
--
--#
--# Networking
--#
--CONFIG_NET=y
--
--#
--# Networking options
--#
--# CONFIG_NET_NS is not set
--CONFIG_PACKET=y
--# CONFIG_PACKET_MMAP is not set
--CONFIG_UNIX=y
--CONFIG_XFRM=y
--# CONFIG_XFRM_USER is not set
--# CONFIG_XFRM_SUB_POLICY is not set
--# CONFIG_XFRM_MIGRATE is not set
--# CONFIG_NET_KEY is not set
--CONFIG_INET=y
--CONFIG_IP_MULTICAST=y
--# CONFIG_IP_ADVANCED_ROUTER is not set
--CONFIG_IP_FIB_HASH=y
--CONFIG_IP_PNP=y
--CONFIG_IP_PNP_DHCP=y
--# CONFIG_IP_PNP_BOOTP is not set
--# CONFIG_IP_PNP_RARP is not set
--# CONFIG_NET_IPIP is not set
--# CONFIG_NET_IPGRE is not set
--# CONFIG_IP_MROUTE is not set
--# CONFIG_ARPD is not set
--# CONFIG_SYN_COOKIES is not set
--# CONFIG_INET_AH is not set
--# CONFIG_INET_ESP is not set
--# CONFIG_INET_IPCOMP is not set
--# CONFIG_INET_XFRM_TUNNEL is not set
--CONFIG_INET_TUNNEL=y
--CONFIG_INET_XFRM_MODE_TRANSPORT=y
--CONFIG_INET_XFRM_MODE_TUNNEL=y
--# CONFIG_INET_XFRM_MODE_BEET is not set
--CONFIG_INET_DIAG=y
--CONFIG_INET_TCP_DIAG=y
--# CONFIG_TCP_CONG_ADVANCED is not set
--CONFIG_TCP_CONG_CUBIC=y
--CONFIG_DEFAULT_TCP_CONG="cubic"
--# CONFIG_TCP_MD5SIG is not set
--# CONFIG_IP_VS is not set
--# CONFIG_ICMP_IPOD is not set
--CONFIG_IPV6=y
--# CONFIG_IPV6_PRIVACY is not set
--# CONFIG_IPV6_ROUTER_PREF is not set
--# CONFIG_IPV6_OPTIMISTIC_DAD is not set
--# CONFIG_INET6_AH is not set
--# CONFIG_INET6_ESP is not set
--# CONFIG_INET6_IPCOMP is not set
--# CONFIG_IPV6_MIP6 is not set
--# CONFIG_INET6_XFRM_TUNNEL is not set
--# CONFIG_INET6_TUNNEL is not set
--CONFIG_INET6_XFRM_MODE_TRANSPORT=y
--CONFIG_INET6_XFRM_MODE_TUNNEL=y
--# CONFIG_INET6_XFRM_MODE_BEET is not set
--# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
--CONFIG_IPV6_SIT=y
--# CONFIG_IPV6_TUNNEL is not set
--# CONFIG_IPV6_MULTIPLE_TABLES is not set
--# CONFIG_NETWORK_SECMARK is not set
--CONFIG_NETFILTER=y
--# CONFIG_NETFILTER_DEBUG is not set
--
--#
--# Core Netfilter Configuration
--#
--# CONFIG_NETFILTER_NETLINK is not set
--CONFIG_NF_CONNTRACK_ENABLED=m
--CONFIG_NF_CONNTRACK=m
--# CONFIG_NF_CT_ACCT is not set
--# CONFIG_NF_CONNTRACK_MARK is not set
--# CONFIG_NF_CONNTRACK_EVENTS is not set
--# CONFIG_NF_CT_PROTO_SCTP is not set
--# CONFIG_NF_CONNTRACK_AMANDA is not set
--# CONFIG_NF_CONNTRACK_FTP is not set
--# CONFIG_NF_CONNTRACK_H323 is not set
--# CONFIG_NF_CONNTRACK_IRC is not set
--# CONFIG_NF_CONNTRACK_NETBIOS_NS is not set
--# CONFIG_NF_CONNTRACK_PPTP is not set
--# CONFIG_NF_CONNTRACK_SANE is not set
--# CONFIG_NF_CONNTRACK_SIP is not set
--# CONFIG_NF_CONNTRACK_TFTP is not set
--CONFIG_NETFILTER_XTABLES=m
--# CONFIG_NETFILTER_XT_TARGET_CLASSIFY is not set
--# CONFIG_NETFILTER_XT_TARGET_CONNMARK is not set
--# CONFIG_NETFILTER_XT_TARGET_DSCP is not set
--# CONFIG_NETFILTER_XT_TARGET_MARK is not set
--# CONFIG_NETFILTER_XT_TARGET_NFQUEUE is not set
--# CONFIG_NETFILTER_XT_TARGET_NFLOG is not set
--# CONFIG_NETFILTER_XT_TARGET_TCPMSS is not set
--# CONFIG_NETFILTER_XT_TARGET_SETXID is not set
--# CONFIG_NETFILTER_XT_MATCH_COMMENT is not set
--# CONFIG_NETFILTER_XT_MATCH_CONNBYTES is not set
--# CONFIG_NETFILTER_XT_MATCH_CONNMARK is not set
--# CONFIG_NETFILTER_XT_MATCH_CONNTRACK is not set
--# CONFIG_NETFILTER_XT_MATCH_DCCP is not set
--# CONFIG_NETFILTER_XT_MATCH_DSCP is not set
--# CONFIG_NETFILTER_XT_MATCH_ESP is not set
--# CONFIG_NETFILTER_XT_MATCH_HELPER is not set
--# CONFIG_NETFILTER_XT_MATCH_LENGTH is not set
--# CONFIG_NETFILTER_XT_MATCH_LIMIT is not set
--# CONFIG_NETFILTER_XT_MATCH_MAC is not set
--# CONFIG_NETFILTER_XT_MATCH_MARK is not set
--# CONFIG_NETFILTER_XT_MATCH_POLICY is not set
--# CONFIG_NETFILTER_XT_MATCH_MULTIPORT is not set
--# CONFIG_NETFILTER_XT_MATCH_PKTTYPE is not set
--# CONFIG_NETFILTER_XT_MATCH_QUOTA is not set
--# CONFIG_NETFILTER_XT_MATCH_REALM is not set
--# CONFIG_NETFILTER_XT_MATCH_SCTP is not set
--# CONFIG_NETFILTER_XT_MATCH_STATE is not set
--# CONFIG_NETFILTER_XT_MATCH_STATISTIC is not set
--# CONFIG_NETFILTER_XT_MATCH_STRING is not set
--# CONFIG_NETFILTER_XT_MATCH_TCPMSS is not set
--# CONFIG_NETFILTER_XT_MATCH_HASHLIMIT is not set
--
--#
--# IP: Netfilter Configuration
--#
--CONFIG_NF_CONNTRACK_IPV4=m
--CONFIG_NF_CONNTRACK_PROC_COMPAT=y
--# CONFIG_IP_NF_QUEUE is not set
--CONFIG_IP_NF_IPTABLES=m
--# CONFIG_IP_NF_MATCH_IPRANGE is not set
--# CONFIG_IP_NF_MATCH_TOS is not set
--# CONFIG_IP_NF_MATCH_RECENT is not set
--# CONFIG_IP_NF_MATCH_ECN is not set
--# CONFIG_IP_NF_MATCH_AH is not set
--# CONFIG_IP_NF_MATCH_TTL is not set
--# CONFIG_IP_NF_MATCH_OWNER is not set
--# CONFIG_IP_NF_MATCH_ADDRTYPE is not set
--CONFIG_IP_NF_FILTER=m
--# CONFIG_IP_NF_TARGET_REJECT is not set
--# CONFIG_IP_NF_TARGET_LOG is not set
--# CONFIG_IP_NF_TARGET_ULOG is not set
--CONFIG_NF_NAT=m
--CONFIG_NF_NAT_NEEDED=y
--# CONFIG_IP_NF_TARGET_MASQUERADE is not set
--# CONFIG_IP_NF_TARGET_REDIRECT is not set
--# CONFIG_IP_NF_TARGET_NETMAP is not set
--# CONFIG_IP_NF_TARGET_SAME is not set
--# CONFIG_NF_NAT_SNMP_BASIC is not set
--# CONFIG_NF_NAT_FTP is not set
--# CONFIG_NF_NAT_IRC is not set
--# CONFIG_NF_NAT_TFTP is not set
--# CONFIG_NF_NAT_AMANDA is not set
--# CONFIG_NF_NAT_PPTP is not set
--# CONFIG_NF_NAT_H323 is not set
--# CONFIG_NF_NAT_SIP is not set
--CONFIG_IP_NF_MANGLE=m
--# CONFIG_IP_NF_TARGET_TOS is not set
--# CONFIG_IP_NF_TARGET_ECN is not set
--# CONFIG_IP_NF_TARGET_TTL is not set
--# CONFIG_IP_NF_TARGET_CLUSTERIP is not set
--# CONFIG_IP_NF_RAW is not set
--# CONFIG_IP_NF_ARPTABLES is not set
--# CONFIG_IP_NF_SET is not set
--
--#
--# IPv6: Netfilter Configuration (EXPERIMENTAL)
--#
--# CONFIG_NF_CONNTRACK_IPV6 is not set
--# CONFIG_IP6_NF_QUEUE is not set
--# CONFIG_IP6_NF_IPTABLES is not set
--# CONFIG_IP_DCCP is not set
--# CONFIG_IP_SCTP is not set
--# CONFIG_TIPC is not set
--# CONFIG_ATM is not set
--# CONFIG_BRIDGE is not set
--# CONFIG_VLAN_8021Q is not set
--# CONFIG_DECNET is not set
--# CONFIG_LLC2 is not set
--# CONFIG_IPX is not set
--# CONFIG_ATALK is not set
--# CONFIG_X25 is not set
--# CONFIG_LAPB is not set
--# CONFIG_ECONET is not set
--# CONFIG_WAN_ROUTER is not set
--
--#
--# QoS and/or fair queueing
--#
--# CONFIG_NET_SCHED is not set
--
--#
--# Network testing
--#
--CONFIG_NET_PKTGEN=m
--# CONFIG_NET_TCPPROBE is not set
--# CONFIG_HAMRADIO is not set
--# CONFIG_IRDA is not set
--# CONFIG_BT is not set
--# CONFIG_AF_RXRPC is not set
--
--#
--# Wireless
--#
--# CONFIG_CFG80211 is not set
--# CONFIG_WIRELESS_EXT is not set
--# CONFIG_MAC80211 is not set
--# CONFIG_IEEE80211 is not set
--# CONFIG_RFKILL is not set
--
--#
--# Device Drivers
--#
--
--#
--# Generic Driver Options
--#
--CONFIG_STANDALONE=y
--CONFIG_PREVENT_FIRMWARE_BUILD=y
--CONFIG_FW_LOADER=y
--# CONFIG_DEBUG_DRIVER is not set
--# CONFIG_DEBUG_DEVRES is not set
--# CONFIG_SYS_HYPERVISOR is not set
--
--#
--# Connector - unified userspace <-> kernelspace linker
--#
--CONFIG_CONNECTOR=m
--# CONFIG_MTD is not set
--
--#
--# Parallel port support
--#
--# CONFIG_PARPORT is not set
--
--#
--# Plug and Play support
--#
--CONFIG_PNP=y
--# CONFIG_PNP_DEBUG is not set
--
--#
--# Protocols
--#
--CONFIG_PNPACPI=y
--
--#
--# Block devices
--#
--CONFIG_BLK_DEV_FD=y
--# CONFIG_BLK_CPQ_DA is not set
--# CONFIG_BLK_CPQ_CISS_DA is not set
--# CONFIG_BLK_DEV_DAC960 is not set
--# CONFIG_BLK_DEV_UMEM is not set
--# CONFIG_BLK_DEV_COW_COMMON is not set
--CONFIG_BLK_DEV_LOOP=y
--# CONFIG_BLK_DEV_CRYPTOLOOP is not set
--# CONFIG_BLK_DEV_NBD is not set
--# CONFIG_BLK_DEV_SX8 is not set
--# CONFIG_BLK_DEV_UB is not set
--CONFIG_BLK_DEV_RAM=y
--CONFIG_BLK_DEV_RAM_COUNT=16
--CONFIG_BLK_DEV_RAM_SIZE=4096
--CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
--# CONFIG_CDROM_PKTCDVD is not set
--# CONFIG_ATA_OVER_ETH is not set
--
--#
--# Misc devices
--#
--# CONFIG_IBM_ASM is not set
--# CONFIG_PHANTOM is not set
--# CONFIG_SGI_IOC4 is not set
--# CONFIG_TIFM_CORE is not set
--# CONFIG_SONY_LAPTOP is not set
--# CONFIG_THINKPAD_ACPI is not set
--CONFIG_IDE=y
--CONFIG_BLK_DEV_IDE=y
--
--#
--# Please see Documentation/ide.txt for help/info on IDE drives
--#
--# CONFIG_BLK_DEV_IDE_SATA is not set
--# CONFIG_BLK_DEV_HD_IDE is not set
--CONFIG_BLK_DEV_IDEDISK=y
--CONFIG_IDEDISK_MULTI_MODE=y
--CONFIG_BLK_DEV_IDECD=y
--# CONFIG_BLK_DEV_IDETAPE is not set
--# CONFIG_BLK_DEV_IDEFLOPPY is not set
--# CONFIG_BLK_DEV_IDESCSI is not set
--# CONFIG_BLK_DEV_IDEACPI is not set
--# CONFIG_IDE_TASK_IOCTL is not set
--CONFIG_IDE_PROC_FS=y
--
--#
--# IDE chipset support/bugfixes
--#
--CONFIG_IDE_GENERIC=y
--# CONFIG_BLK_DEV_CMD640 is not set
--# CONFIG_BLK_DEV_IDEPNP is not set
--CONFIG_BLK_DEV_IDEPCI=y
--# CONFIG_IDEPCI_SHARE_IRQ is not set
--CONFIG_IDEPCI_PCIBUS_ORDER=y
--# CONFIG_BLK_DEV_OFFBOARD is not set
--# CONFIG_BLK_DEV_GENERIC is not set
--# CONFIG_BLK_DEV_OPTI621 is not set
--# CONFIG_BLK_DEV_RZ1000 is not set
--CONFIG_BLK_DEV_IDEDMA_PCI=y
--# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
--# CONFIG_IDEDMA_ONLYDISK is not set
--# CONFIG_BLK_DEV_AEC62XX is not set
--# CONFIG_BLK_DEV_ALI15X3 is not set
--CONFIG_BLK_DEV_AMD74XX=y
--# CONFIG_BLK_DEV_ATIIXP is not set
--# CONFIG_BLK_DEV_CMD64X is not set
--# CONFIG_BLK_DEV_TRIFLEX is not set
--# CONFIG_BLK_DEV_CY82C693 is not set
--# CONFIG_BLK_DEV_CS5520 is not set
--# CONFIG_BLK_DEV_CS5530 is not set
--# CONFIG_BLK_DEV_CS5535 is not set
--# CONFIG_BLK_DEV_HPT34X is not set
--# CONFIG_BLK_DEV_HPT366 is not set
--# CONFIG_BLK_DEV_JMICRON is not set
--# CONFIG_BLK_DEV_SC1200 is not set
--CONFIG_BLK_DEV_PIIX=y
--# CONFIG_BLK_DEV_IT8213 is not set
--# CONFIG_BLK_DEV_IT821X is not set
--# CONFIG_BLK_DEV_NS87415 is not set
--# CONFIG_BLK_DEV_PDC202XX_OLD is not set
--# CONFIG_BLK_DEV_PDC202XX_NEW is not set
--# CONFIG_BLK_DEV_SVWKS is not set
--# CONFIG_BLK_DEV_SIIMAGE is not set
--# CONFIG_BLK_DEV_SIS5513 is not set
--# CONFIG_BLK_DEV_SLC90E66 is not set
--# CONFIG_BLK_DEV_TRM290 is not set
--# CONFIG_BLK_DEV_VIA82CXXX is not set
--# CONFIG_BLK_DEV_TC86C001 is not set
--# CONFIG_IDE_ARM is not set
--CONFIG_BLK_DEV_IDEDMA=y
--# CONFIG_IDEDMA_IVB is not set
--# CONFIG_BLK_DEV_HD is not set
--
--#
--# SCSI device support
--#
--# CONFIG_RAID_ATTRS is not set
--CONFIG_SCSI=y
--# CONFIG_SCSI_TGT is not set
--CONFIG_SCSI_NETLINK=y
--# CONFIG_SCSI_PROC_FS is not set
--
--#
--# SCSI support type (disk, tape, CD-ROM)
--#
--CONFIG_BLK_DEV_SD=y
--# CONFIG_CHR_DEV_ST is not set
--# CONFIG_CHR_DEV_OSST is not set
--CONFIG_BLK_DEV_SR=y
--# CONFIG_BLK_DEV_SR_VENDOR is not set
--CONFIG_CHR_DEV_SG=y
--# CONFIG_CHR_DEV_SCH is not set
--
--#
--# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
--#
--# CONFIG_SCSI_MULTI_LUN is not set
--# CONFIG_SCSI_CONSTANTS is not set
--# CONFIG_SCSI_LOGGING is not set
--# CONFIG_SCSI_SCAN_ASYNC is not set
--CONFIG_SCSI_WAIT_SCAN=m
--
--#
--# SCSI Transports
--#
--CONFIG_SCSI_SPI_ATTRS=y
--CONFIG_SCSI_FC_ATTRS=y
--# CONFIG_SCSI_ISCSI_ATTRS is not set
--# CONFIG_SCSI_SAS_ATTRS is not set
--# CONFIG_SCSI_SAS_LIBSAS is not set
--
--#
--# SCSI low-level drivers
--#
--# CONFIG_ISCSI_TCP is not set
--CONFIG_BLK_DEV_3W_XXXX_RAID=y
--# CONFIG_SCSI_3W_9XXX is not set
--# CONFIG_SCSI_ACARD is not set
--# CONFIG_SCSI_AACRAID is not set
--CONFIG_SCSI_AIC7XXX=y
--CONFIG_AIC7XXX_CMDS_PER_DEVICE=32
--CONFIG_AIC7XXX_RESET_DELAY_MS=5000
--CONFIG_AIC7XXX_DEBUG_ENABLE=y
--CONFIG_AIC7XXX_DEBUG_MASK=0
--CONFIG_AIC7XXX_REG_PRETTY_PRINT=y
--# CONFIG_SCSI_AIC7XXX_OLD is not set
--CONFIG_SCSI_AIC79XX=y
--CONFIG_AIC79XX_CMDS_PER_DEVICE=32
--CONFIG_AIC79XX_RESET_DELAY_MS=4000
--# CONFIG_AIC79XX_DEBUG_ENABLE is not set
--CONFIG_AIC79XX_DEBUG_MASK=0
--# CONFIG_AIC79XX_REG_PRETTY_PRINT is not set
--# CONFIG_SCSI_AIC94XX is not set
--# CONFIG_SCSI_DPT_I2O is not set
--# CONFIG_SCSI_ADVANSYS is not set
--# CONFIG_SCSI_ARCMSR is not set
--# CONFIG_MEGARAID_NEWGEN is not set
--# CONFIG_MEGARAID_LEGACY is not set
--# CONFIG_MEGARAID_SAS is not set
--# CONFIG_SCSI_HPTIOP is not set
--# CONFIG_SCSI_BUSLOGIC is not set
--# CONFIG_SCSI_DMX3191D is not set
--# CONFIG_SCSI_EATA is not set
--# CONFIG_SCSI_FUTURE_DOMAIN is not set
--# CONFIG_SCSI_GDTH is not set
--# CONFIG_SCSI_IPS is not set
--# CONFIG_SCSI_INITIO is not set
--# CONFIG_SCSI_INIA100 is not set
--# CONFIG_SCSI_STEX is not set
--# CONFIG_SCSI_SYM53C8XX_2 is not set
--# CONFIG_SCSI_IPR is not set
--# CONFIG_SCSI_QLOGIC_1280 is not set
--# CONFIG_SCSI_QLA_FC is not set
--# CONFIG_SCSI_QLA_ISCSI is not set
--# CONFIG_SCSI_LPFC is not set
--# CONFIG_SCSI_DC395x is not set
--# CONFIG_SCSI_DC390T is not set
--# CONFIG_SCSI_NSP32 is not set
--# CONFIG_SCSI_DEBUG is not set
--# CONFIG_SCSI_SRP is not set
--CONFIG_ATA=y
--# CONFIG_ATA_NONSTANDARD is not set
--CONFIG_ATA_ACPI=y
--CONFIG_SATA_AHCI=y
--CONFIG_SATA_SVW=y
--CONFIG_ATA_PIIX=y
--# CONFIG_SATA_MV is not set
--CONFIG_SATA_NV=y
--# CONFIG_PDC_ADMA is not set
--# CONFIG_SATA_QSTOR is not set
--# CONFIG_SATA_PROMISE is not set
--# CONFIG_SATA_SX4 is not set
--CONFIG_SATA_SIL=y
--# CONFIG_SATA_SIL24 is not set
--# CONFIG_SATA_SIS is not set
--# CONFIG_SATA_ULI is not set
--CONFIG_SATA_VIA=y
--# CONFIG_SATA_VITESSE is not set
--# CONFIG_SATA_INIC162X is not set
--# CONFIG_PATA_ALI is not set
--# CONFIG_PATA_AMD is not set
--# CONFIG_PATA_ARTOP is not set
--# CONFIG_PATA_ATIIXP is not set
--# CONFIG_PATA_CMD640_PCI is not set
--# CONFIG_PATA_CMD64X is not set
--# CONFIG_PATA_CS5520 is not set
--# CONFIG_PATA_CS5530 is not set
--# CONFIG_PATA_CS5535 is not set
--# CONFIG_PATA_CYPRESS is not set
--# CONFIG_PATA_EFAR is not set
--# CONFIG_ATA_GENERIC is not set
--# CONFIG_PATA_HPT366 is not set
--# CONFIG_PATA_HPT37X is not set
--# CONFIG_PATA_HPT3X2N is not set
--# CONFIG_PATA_HPT3X3 is not set
--# CONFIG_PATA_IT821X is not set
--# CONFIG_PATA_IT8213 is not set
--# CONFIG_PATA_JMICRON is not set
--# CONFIG_PATA_TRIFLEX is not set
--# CONFIG_PATA_MARVELL is not set
--# CONFIG_PATA_MPIIX is not set
--# CONFIG_PATA_OLDPIIX is not set
--# CONFIG_PATA_NETCELL is not set
--# CONFIG_PATA_NS87410 is not set
--# CONFIG_PATA_OPTI is not set
--# CONFIG_PATA_OPTIDMA is not set
--# CONFIG_PATA_PDC_OLD is not set
--# CONFIG_PATA_RADISYS is not set
--# CONFIG_PATA_RZ1000 is not set
--# CONFIG_PATA_SC1200 is not set
--# CONFIG_PATA_SERVERWORKS is not set
--# CONFIG_PATA_PDC2027X is not set
--# CONFIG_PATA_SIL680 is not set
--# CONFIG_PATA_SIS is not set
--# CONFIG_PATA_VIA is not set
--# CONFIG_PATA_WINBOND is not set
--
--#
--# Multi-device support (RAID and LVM)
--#
--CONFIG_MD=y
--# CONFIG_BLK_DEV_MD is not set
--CONFIG_BLK_DEV_DM=y
--# CONFIG_DM_DEBUG is not set
--# CONFIG_DM_CRYPT is not set
--# CONFIG_DM_SNAPSHOT is not set
--# CONFIG_DM_MIRROR is not set
--# CONFIG_DM_ZERO is not set
--# CONFIG_DM_MULTIPATH is not set
--# CONFIG_DM_DELAY is not set
--# CONFIG_DM_NETLINK is not set
--
--#
--# Fusion MPT device support
--#
--CONFIG_FUSION=y
--CONFIG_FUSION_SPI=y
--# CONFIG_FUSION_FC is not set
--# CONFIG_FUSION_SAS is not set
--CONFIG_FUSION_MAX_SGE=128
--# CONFIG_FUSION_CTL is not set
--
--#
--# IEEE 1394 (FireWire) support
--#
--# CONFIG_FIREWIRE is not set
--CONFIG_IEEE1394=y
--
--#
--# Subsystem Options
--#
--# CONFIG_IEEE1394_VERBOSEDEBUG is not set
--
--#
--# Controllers
--#
--
--#
--# Texas Instruments PCILynx requires I2C
--#
--CONFIG_IEEE1394_OHCI1394=y
--
--#
--# Protocols
--#
--# CONFIG_IEEE1394_VIDEO1394 is not set
--# CONFIG_IEEE1394_SBP2 is not set
--# CONFIG_IEEE1394_ETH1394_ROM_ENTRY is not set
--# CONFIG_IEEE1394_ETH1394 is not set
--# CONFIG_IEEE1394_DV1394 is not set
--CONFIG_IEEE1394_RAWIO=y
--
--#
--# I2O device support
--#
--# CONFIG_I2O is not set
--# CONFIG_MACINTOSH_DRIVERS is not set
--
--#
--# Network device support
--#
--CONFIG_NETDEVICES=y
--# CONFIG_DUMMY is not set
--# CONFIG_BONDING is not set
--# CONFIG_EQUALIZER is not set
--CONFIG_TUN=m
--# CONFIG_ETUN is not set
--# CONFIG_NET_SB1000 is not set
--# CONFIG_ARCNET is not set
--# CONFIG_PHYLIB is not set
--
--#
--# Ethernet (10 or 100Mbit)
--#
--CONFIG_NET_ETHERNET=y
--CONFIG_MII=y
--# CONFIG_HAPPYMEAL is not set
--# CONFIG_SUNGEM is not set
--# CONFIG_CASSINI is not set
--# CONFIG_NET_VENDOR_3COM is not set
--
--#
--# Tulip family network device support
--#
--CONFIG_NET_TULIP=y
--# CONFIG_DE2104X is not set
--CONFIG_TULIP=y
--# CONFIG_TULIP_MWI is not set
--# CONFIG_TULIP_MMIO is not set
--# CONFIG_TULIP_NAPI is not set
--# CONFIG_DE4X5 is not set
--# CONFIG_WINBOND_840 is not set
--# CONFIG_DM9102 is not set
--# CONFIG_ULI526X is not set
--# CONFIG_HP100 is not set
--CONFIG_NET_PCI=y
--# CONFIG_PCNET32 is not set
--# CONFIG_AMD8111_ETH is not set
--# CONFIG_ADAPTEC_STARFIRE is not set
--CONFIG_B44=y
--CONFIG_FORCEDETH=y
--# CONFIG_FORCEDETH_NAPI is not set
--# CONFIG_DGRS is not set
--# CONFIG_EEPRO100 is not set
--CONFIG_E100=y
--# CONFIG_FEALNX is not set
--# CONFIG_NATSEMI is not set
--# CONFIG_NE2K_PCI is not set
--CONFIG_8139CP=y
--CONFIG_8139TOO=y
--# CONFIG_8139TOO_PIO is not set
--# CONFIG_8139TOO_TUNE_TWISTER is not set
--# CONFIG_8139TOO_8129 is not set
--# CONFIG_8139_OLD_RX_RESET is not set
--# CONFIG_SIS900 is not set
--# CONFIG_EPIC100 is not set
--# CONFIG_SUNDANCE is not set
--# CONFIG_TLAN is not set
--# CONFIG_VIA_RHINE is not set
--# CONFIG_SC92031 is not set
--CONFIG_NETDEV_1000=y
--# CONFIG_ACENIC is not set
--# CONFIG_DL2K is not set
--CONFIG_E1000=y
--# CONFIG_E1000_NAPI is not set
--# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set
--# CONFIG_E1000E is not set
--# CONFIG_NS83820 is not set
--# CONFIG_HAMACHI is not set
--# CONFIG_YELLOWFIN is not set
--CONFIG_R8169=y
--# CONFIG_R8169_NAPI is not set
--# CONFIG_SIS190 is not set
--# CONFIG_SKGE is not set
--CONFIG_SKY2=y
--# CONFIG_SK98LIN is not set
--# CONFIG_VIA_VELOCITY is not set
--CONFIG_TIGON3=y
--CONFIG_BNX2=y
--# CONFIG_QLA3XXX is not set
--# CONFIG_ATL1 is not set
--CONFIG_NETDEV_10000=y
--# CONFIG_CHELSIO_T1 is not set
--# CONFIG_CHELSIO_T3 is not set
--# CONFIG_IXGB is not set
--# CONFIG_S2IO is not set
--# CONFIG_MYRI10GE is not set
--# CONFIG_NETXEN_NIC is not set
--# CONFIG_MLX4_CORE is not set
--# CONFIG_TR is not set
--
--#
--# Wireless LAN
--#
--# CONFIG_WLAN_PRE80211 is not set
--# CONFIG_WLAN_80211 is not set
--
--#
--# USB Network Adapters
--#
--# CONFIG_USB_CATC is not set
--# CONFIG_USB_KAWETH is not set
--# CONFIG_USB_PEGASUS is not set
--# CONFIG_USB_RTL8150 is not set
--# CONFIG_USB_USBNET_MII is not set
--# CONFIG_USB_USBNET is not set
--# CONFIG_WAN is not set
--# CONFIG_FDDI is not set
--# CONFIG_HIPPI is not set
--CONFIG_PPP=m
--# CONFIG_PPP_MULTILINK is not set
--# CONFIG_PPP_FILTER is not set
--# CONFIG_PPP_ASYNC is not set
--# CONFIG_PPP_SYNC_TTY is not set
--# CONFIG_PPP_DEFLATE is not set
--# CONFIG_PPP_BSDCOMP is not set
--# CONFIG_PPP_MPPE is not set
--# CONFIG_PPPOE is not set
--# CONFIG_SLIP is not set
--CONFIG_SLHC=m
--# CONFIG_NET_FC is not set
--# CONFIG_SHAPER is not set
--CONFIG_NETCONSOLE=y
--CONFIG_NETPOLL=y
--# CONFIG_NETPOLL_TRAP is not set
--CONFIG_NET_POLL_CONTROLLER=y
--
--#
--# ISDN subsystem
--#
--# CONFIG_ISDN is not set
--
--#
--# Telephony Support
--#
--# CONFIG_PHONE is not set
--
--#
--# Input device support
--#
--CONFIG_INPUT=y
--# CONFIG_INPUT_FF_MEMLESS is not set
--# CONFIG_INPUT_POLLDEV is not set
--
--#
--# Userland interfaces
--#
--CONFIG_INPUT_MOUSEDEV=y
--CONFIG_INPUT_MOUSEDEV_PSAUX=y
--CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
--CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
--# CONFIG_INPUT_JOYDEV is not set
--# CONFIG_INPUT_TSDEV is not set
--CONFIG_INPUT_EVDEV=y
--# CONFIG_INPUT_EVBUG is not set
--
--#
--# Input Device Drivers
--#
--CONFIG_INPUT_KEYBOARD=y
--CONFIG_KEYBOARD_ATKBD=y
--# CONFIG_KEYBOARD_SUNKBD is not set
--# CONFIG_KEYBOARD_LKKBD is not set
--# CONFIG_KEYBOARD_XTKBD is not set
--# CONFIG_KEYBOARD_NEWTON is not set
--# CONFIG_KEYBOARD_STOWAWAY is not set
--CONFIG_INPUT_MOUSE=y
--CONFIG_MOUSE_PS2=y
--CONFIG_MOUSE_PS2_ALPS=y
--CONFIG_MOUSE_PS2_LOGIPS2PP=y
--CONFIG_MOUSE_PS2_SYNAPTICS=y
--CONFIG_MOUSE_PS2_LIFEBOOK=y
--CONFIG_MOUSE_PS2_TRACKPOINT=y
--# CONFIG_MOUSE_PS2_TOUCHKIT is not set
--# CONFIG_MOUSE_SERIAL is not set
--# CONFIG_MOUSE_APPLETOUCH is not set
--# CONFIG_MOUSE_VSXXXAA is not set
--# CONFIG_INPUT_JOYSTICK is not set
--# CONFIG_INPUT_TABLET is not set
--# CONFIG_INPUT_TOUCHSCREEN is not set
--# CONFIG_INPUT_MISC is not set
--
--#
--# Hardware I/O ports
--#
--CONFIG_SERIO=y
--CONFIG_SERIO_I8042=y
--# CONFIG_SERIO_SERPORT is not set
--# CONFIG_SERIO_CT82C710 is not set
--# CONFIG_SERIO_PCIPS2 is not set
--CONFIG_SERIO_LIBPS2=y
--# CONFIG_SERIO_RAW is not set
--# CONFIG_GAMEPORT is not set
--
--#
--# Character devices
--#
--CONFIG_VT=y
--CONFIG_VT_CONSOLE=y
--CONFIG_HW_CONSOLE=y
--# CONFIG_VT_HW_CONSOLE_BINDING is not set
--# CONFIG_SERIAL_NONSTANDARD is not set
--
--#
--# Serial drivers
--#
--CONFIG_SERIAL_8250=y
--CONFIG_SERIAL_8250_CONSOLE=y
--CONFIG_SERIAL_8250_PCI=y
--CONFIG_SERIAL_8250_PNP=y
--CONFIG_SERIAL_8250_NR_UARTS=4
--CONFIG_SERIAL_8250_RUNTIME_UARTS=4
--# CONFIG_SERIAL_8250_EXTENDED is not set
--
--#
--# Non-8250 serial port support
--#
--CONFIG_SERIAL_CORE=y
--CONFIG_SERIAL_CORE_CONSOLE=y
--# CONFIG_SERIAL_JSM is not set
--CONFIG_UNIX98_PTYS=y
--CONFIG_LEGACY_PTYS=y
--CONFIG_LEGACY_PTY_COUNT=256
--
--#
--# IPMI
--#
--# CONFIG_IPMI_HANDLER is not set
--# CONFIG_WATCHDOG is not set
--CONFIG_HW_RANDOM=y
--CONFIG_HW_RANDOM_INTEL=y
--CONFIG_HW_RANDOM_AMD=y
--CONFIG_HW_RANDOM_GEODE=y
--CONFIG_HW_RANDOM_VIA=y
--# CONFIG_NVRAM is not set
--CONFIG_RTC=y
--# CONFIG_R3964 is not set
--# CONFIG_APPLICOM is not set
--# CONFIG_SONYPI is not set
--# CONFIG_AGP is not set
--# CONFIG_DRM is not set
--# CONFIG_MWAVE is not set
--# CONFIG_PC8736x_GPIO is not set
--# CONFIG_NSC_GPIO is not set
--# CONFIG_CS5535_GPIO is not set
--CONFIG_RAW_DRIVER=y
--CONFIG_MAX_RAW_DEVS=256
--CONFIG_HPET=y
--# CONFIG_HPET_RTC_IRQ is not set
--CONFIG_HPET_MMAP=y
--CONFIG_HANGCHECK_TIMER=y
--
--#
--# TPM devices
--#
--# CONFIG_TCG_TPM is not set
--# CONFIG_TELCLOCK is not set
--CONFIG_DEVPORT=y
--# CONFIG_I2C is not set
--
--#
--# SPI support
--#
--# CONFIG_SPI is not set
--# CONFIG_SPI_MASTER is not set
--
--#
--# Dallas's 1-wire bus
--#
--# CONFIG_W1 is not set
--# CONFIG_HWMON is not set
--
--#
--# Multifunction device drivers
--#
--# CONFIG_MFD_SM501 is not set
--
--#
--# Multimedia devices
--#
--# CONFIG_VIDEO_DEV is not set
--# CONFIG_DVB_CORE is not set
--CONFIG_DAB=y
--# CONFIG_USB_DABUSB is not set
--
--#
--# Graphics support
--#
--# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
--
--#
--# Display device support
--#
--# CONFIG_DISPLAY_SUPPORT is not set
--# CONFIG_VGASTATE is not set
--CONFIG_VIDEO_OUTPUT_CONTROL=m
--# CONFIG_FB is not set
--
--#
--# Console display driver support
--#
--CONFIG_VGA_CONSOLE=y
--CONFIG_VGACON_SOFT_SCROLLBACK=y
--CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=128
--CONFIG_VIDEO_SELECT=y
--CONFIG_DUMMY_CONSOLE=y
--
--#
--# Sound
--#
--CONFIG_SOUND=y
--
--#
--# Advanced Linux Sound Architecture
--#
--# CONFIG_SND is not set
--
--#
--# Open Sound System
--#
--CONFIG_SOUND_PRIME=y
--# CONFIG_OSS_OBSOLETE is not set
--# CONFIG_SOUND_TRIDENT is not set
--# CONFIG_SOUND_MSNDCLAS is not set
--# CONFIG_SOUND_MSNDPIN is not set
--# CONFIG_SOUND_OSS is not set
--
--#
--# HID Devices
--#
--CONFIG_HID=y
--# CONFIG_HID_DEBUG is not set
--
--#
--# USB Input Devices
--#
--CONFIG_USB_HID=y
--# CONFIG_USB_HIDINPUT_POWERBOOK is not set
--# CONFIG_HID_FF is not set
--# CONFIG_USB_HIDDEV is not set
--
--#
--# USB support
--#
--CONFIG_USB_ARCH_HAS_HCD=y
--CONFIG_USB_ARCH_HAS_OHCI=y
--CONFIG_USB_ARCH_HAS_EHCI=y
--CONFIG_USB=y
--# CONFIG_USB_DEBUG is not set
--
--#
--# Miscellaneous USB options
--#
--CONFIG_USB_DEVICEFS=y
--CONFIG_USB_DEVICE_CLASS=y
--# CONFIG_USB_DYNAMIC_MINORS is not set
--# CONFIG_USB_SUSPEND is not set
--# CONFIG_USB_OTG is not set
--
--#
--# USB Host Controller Drivers
--#
--CONFIG_USB_EHCI_HCD=y
--# CONFIG_USB_EHCI_SPLIT_ISO is not set
--# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
--# CONFIG_USB_EHCI_TT_NEWSCHED is not set
--# CONFIG_USB_EHCI_BIG_ENDIAN_MMIO is not set
--# CONFIG_USB_ISP116X_HCD is not set
--CONFIG_USB_OHCI_HCD=y
--# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
--# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
--CONFIG_USB_OHCI_LITTLE_ENDIAN=y
--CONFIG_USB_UHCI_HCD=y
--# CONFIG_USB_SL811_HCD is not set
--
--#
--# USB Device Class drivers
--#
--# CONFIG_USB_ACM is not set
--CONFIG_USB_PRINTER=y
--
--#
--# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
--#
--
--#
--# may also be needed; see USB_STORAGE Help for more information
--#
--CONFIG_USB_STORAGE=y
--# CONFIG_USB_STORAGE_DEBUG is not set
--# CONFIG_USB_STORAGE_DATAFAB is not set
--# CONFIG_USB_STORAGE_FREECOM is not set
--# CONFIG_USB_STORAGE_ISD200 is not set
--# CONFIG_USB_STORAGE_DPCM is not set
--# CONFIG_USB_STORAGE_USBAT is not set
--# CONFIG_USB_STORAGE_SDDR09 is not set
--# CONFIG_USB_STORAGE_SDDR55 is not set
--# CONFIG_USB_STORAGE_JUMPSHOT is not set
--# CONFIG_USB_STORAGE_ALAUDA is not set
--# CONFIG_USB_STORAGE_KARMA is not set
--# CONFIG_USB_LIBUSUAL is not set
--
--#
--# USB Imaging devices
--#
--# CONFIG_USB_MDC800 is not set
--# CONFIG_USB_MICROTEK is not set
--CONFIG_USB_MON=y
--
--#
--# USB port drivers
--#
--
--#
--# USB Serial Converter support
--#
--# CONFIG_USB_SERIAL is not set
--
--#
--# USB Miscellaneous drivers
--#
--# CONFIG_USB_EMI62 is not set
--# CONFIG_USB_EMI26 is not set
--# CONFIG_USB_ADUTUX is not set
--# CONFIG_USB_AUERSWALD is not set
--# CONFIG_USB_RIO500 is not set
--# CONFIG_USB_LEGOTOWER is not set
--# CONFIG_USB_LCD is not set
--# CONFIG_USB_BERRY_CHARGE is not set
--# CONFIG_USB_LED is not set
--# CONFIG_USB_CYPRESS_CY7C63 is not set
--# CONFIG_USB_CYTHERM is not set
--# CONFIG_USB_PHIDGET is not set
--# CONFIG_USB_IDMOUSE is not set
--# CONFIG_USB_FTDI_ELAN is not set
--# CONFIG_USB_APPLEDISPLAY is not set
--# CONFIG_USB_SISUSBVGA is not set
--# CONFIG_USB_LD is not set
--# CONFIG_USB_TRANCEVIBRATOR is not set
--# CONFIG_USB_IOWARRIOR is not set
--# CONFIG_USB_TEST is not set
--
--#
--# USB DSL modem support
--#
--
--#
--# USB Gadget Support
--#
--# CONFIG_USB_GADGET is not set
--# CONFIG_MMC is not set
--
--#
--# LED devices
--#
--# CONFIG_NEW_LEDS is not set
--
--#
--# LED drivers
--#
--
--#
--# LED Triggers
--#
--
--#
--# InfiniBand support
--#
--# CONFIG_INFINIBAND is not set
--
--#
--# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
--#
--# CONFIG_EDAC is not set
--
--#
--# Real Time Clock
--#
--# CONFIG_RTC_CLASS is not set
--
--#
--# DMA Engine support
--#
--# CONFIG_DMA_ENGINE is not set
--
--#
--# DMA Clients
--#
--
--#
--# DMA Devices
--#
--
--#
--# Virtualization
--#
--# CONFIG_KVM is not set
--
--#
--# File systems
--#
--CONFIG_EXT2_FS=y
--CONFIG_EXT2_FS_XATTR=y
--CONFIG_EXT2_FS_POSIX_ACL=y
--# CONFIG_EXT2_FS_SECURITY is not set
--# CONFIG_EXT2_FS_XIP is not set
--CONFIG_EXT3_FS=y
--CONFIG_EXT3_FS_XATTR=y
--CONFIG_EXT3_FS_POSIX_ACL=y
--# CONFIG_EXT3_FS_SECURITY is not set
--# CONFIG_EXT4DEV_FS is not set
--CONFIG_JBD=y
--# CONFIG_JBD_DEBUG is not set
--CONFIG_FS_MBCACHE=y
--CONFIG_REISERFS_FS=y
--# CONFIG_REISERFS_CHECK is not set
--# CONFIG_REISERFS_PROC_INFO is not set
--CONFIG_REISERFS_FS_XATTR=y
--CONFIG_REISERFS_FS_POSIX_ACL=y
--# CONFIG_REISERFS_FS_SECURITY is not set
--# CONFIG_JFS_FS is not set
--CONFIG_FS_POSIX_ACL=y
--# CONFIG_XFS_FS is not set
--# CONFIG_GFS2_FS is not set
--# CONFIG_OCFS2_FS is not set
--# CONFIG_MINIX_FS is not set
--# CONFIG_ROMFS_FS is not set
--CONFIG_INOTIFY=y
--CONFIG_INOTIFY_USER=y
--# CONFIG_QUOTA is not set
--CONFIG_DNOTIFY=y
--# CONFIG_AUTOFS_FS is not set
--CONFIG_AUTOFS4_FS=y
--CONFIG_FUSE_FS=m
--CONFIG_GENERIC_ACL=y
--
--#
--# CD-ROM/DVD Filesystems
--#
--CONFIG_ISO9660_FS=y
--# CONFIG_JOLIET is not set
--# CONFIG_ZISOFS is not set
--CONFIG_UDF_FS=m
--CONFIG_UDF_NLS=y
--
--#
--# DOS/FAT/NT Filesystems
--#
--CONFIG_FAT_FS=y
--CONFIG_MSDOS_FS=y
--CONFIG_VFAT_FS=y
--CONFIG_FAT_DEFAULT_CODEPAGE=437
--CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
--CONFIG_NTFS_FS=m
--# CONFIG_NTFS_DEBUG is not set
--CONFIG_NTFS_RW=y
--
--#
--# Pseudo filesystems
--#
--CONFIG_PROC_FS=y
--CONFIG_PROC_KCORE=y
--CONFIG_PROC_SYSCTL=y
--CONFIG_SYSFS=y
--CONFIG_TMPFS=y
--CONFIG_TMPFS_POSIX_ACL=y
--CONFIG_HUGETLBFS=y
--CONFIG_HUGETLB_PAGE=y
--CONFIG_RAMFS=y
--# CONFIG_CONFIGFS_FS is not set
--
--#
--# Layered filesystems
--#
--# CONFIG_UNION_FS is not set
--
--#
--# Miscellaneous filesystems
--#
--# CONFIG_ADFS_FS is not set
--# CONFIG_AFFS_FS is not set
--# CONFIG_HFS_FS is not set
--# CONFIG_HFSPLUS_FS is not set
--# CONFIG_BEFS_FS is not set
--# CONFIG_BFS_FS is not set
--# CONFIG_EFS_FS is not set
--# CONFIG_CRAMFS is not set
--# CONFIG_VXFS_FS is not set
--# CONFIG_HPFS_FS is not set
--# CONFIG_QNX4FS_FS is not set
--# CONFIG_SYSV_FS is not set
--# CONFIG_UFS_FS is not set
--
--#
--# Network File Systems
--#
--CONFIG_NFS_FS=y
--CONFIG_NFS_V3=y
--# CONFIG_NFS_V3_ACL is not set
--# CONFIG_NFS_V4 is not set
--# CONFIG_NFS_DIRECTIO is not set
--CONFIG_NFSD=y
--CONFIG_NFSD_V3=y
--# CONFIG_NFSD_V3_ACL is not set
--# CONFIG_NFSD_V4 is not set
--CONFIG_NFSD_TCP=y
--CONFIG_ROOT_NFS=y
--CONFIG_LOCKD=y
--CONFIG_LOCKD_V4=y
--CONFIG_EXPORTFS=y
--CONFIG_NFS_COMMON=y
--CONFIG_SUNRPC=y
--# CONFIG_SUNRPC_BIND34 is not set
--# CONFIG_RPCSEC_GSS_KRB5 is not set
--# CONFIG_RPCSEC_GSS_SPKM3 is not set
--CONFIG_SMB_FS=m
--# CONFIG_SMB_NLS_DEFAULT is not set
--# CONFIG_CIFS is not set
--# CONFIG_NCP_FS is not set
--# CONFIG_CODA_FS is not set
--# CONFIG_AFS_FS is not set
--# CONFIG_9P_FS is not set
--
--#
--# Partition Types
--#
--# CONFIG_PARTITION_ADVANCED is not set
--CONFIG_MSDOS_PARTITION=y
--
--#
--# Native Language Support
--#
--CONFIG_NLS=y
--CONFIG_NLS_DEFAULT="iso8859-1"
--CONFIG_NLS_CODEPAGE_437=y
--# CONFIG_NLS_CODEPAGE_737 is not set
--# CONFIG_NLS_CODEPAGE_775 is not set
--CONFIG_NLS_CODEPAGE_850=y
--CONFIG_NLS_CODEPAGE_852=y
--# CONFIG_NLS_CODEPAGE_855 is not set
--# CONFIG_NLS_CODEPAGE_857 is not set
--# CONFIG_NLS_CODEPAGE_860 is not set
--# CONFIG_NLS_CODEPAGE_861 is not set
--# CONFIG_NLS_CODEPAGE_862 is not set
--# CONFIG_NLS_CODEPAGE_863 is not set
--# CONFIG_NLS_CODEPAGE_864 is not set
--# CONFIG_NLS_CODEPAGE_865 is not set
--# CONFIG_NLS_CODEPAGE_866 is not set
--# CONFIG_NLS_CODEPAGE_869 is not set
--# CONFIG_NLS_CODEPAGE_936 is not set
--# CONFIG_NLS_CODEPAGE_950 is not set
--# CONFIG_NLS_CODEPAGE_932 is not set
--# CONFIG_NLS_CODEPAGE_949 is not set
--# CONFIG_NLS_CODEPAGE_874 is not set
--# CONFIG_NLS_ISO8859_8 is not set
--# CONFIG_NLS_CODEPAGE_1250 is not set
--# CONFIG_NLS_CODEPAGE_1251 is not set
--CONFIG_NLS_ASCII=y
--CONFIG_NLS_ISO8859_1=y
--CONFIG_NLS_ISO8859_2=y
--# CONFIG_NLS_ISO8859_3 is not set
--# CONFIG_NLS_ISO8859_4 is not set
--# CONFIG_NLS_ISO8859_5 is not set
--# CONFIG_NLS_ISO8859_6 is not set
--# CONFIG_NLS_ISO8859_7 is not set
--# CONFIG_NLS_ISO8859_9 is not set
--# CONFIG_NLS_ISO8859_13 is not set
--# CONFIG_NLS_ISO8859_14 is not set
--CONFIG_NLS_ISO8859_15=y
--# CONFIG_NLS_KOI8_R is not set
--# CONFIG_NLS_KOI8_U is not set
--CONFIG_NLS_UTF8=y
--
--#
--# Distributed Lock Manager
--#
--# CONFIG_DLM is not set
--
--#
--# Instrumentation Support
--#
--CONFIG_PROFILING=y
--CONFIG_OPROFILE=y
--CONFIG_KPROBES=y
--
--#
--# Kernel hacking
--#
--CONFIG_TRACE_IRQFLAGS_SUPPORT=y
--CONFIG_PRINTK_TIME=y
--# CONFIG_ENABLE_MUST_CHECK is not set
--CONFIG_MAGIC_SYSRQ=y
--CONFIG_UNUSED_SYMBOLS=y
--# CONFIG_DEBUG_FS is not set
--# CONFIG_HEADERS_CHECK is not set
--CONFIG_DEBUG_KERNEL=y
--# CONFIG_DEBUG_SHIRQ is not set
--CONFIG_DETECT_SOFTLOCKUP=y
--# CONFIG_SCHEDSTATS is not set
--# CONFIG_TIMER_STATS is not set
--# CONFIG_DEBUG_SLAB is not set
--# CONFIG_DEBUG_RT_MUTEXES is not set
--# CONFIG_RT_MUTEX_TESTER is not set
--# CONFIG_DEBUG_SPINLOCK is not set
--# CONFIG_DEBUG_MUTEXES is not set
--# CONFIG_DEBUG_LOCK_ALLOC is not set
--# CONFIG_PROVE_LOCKING is not set
--# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
--# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
--# CONFIG_DEBUG_KOBJECT is not set
--# CONFIG_DEBUG_HIGHMEM is not set
--CONFIG_DEBUG_BUGVERBOSE=y
--CONFIG_DEBUG_INFO=y
--# CONFIG_DEBUG_VM is not set
--# CONFIG_DEBUG_LIST is not set
--# CONFIG_FRAME_POINTER is not set
--# CONFIG_UNWIND_INFO is not set
--# CONFIG_FORCED_INLINING is not set
--# CONFIG_RCU_TORTURE_TEST is not set
--# CONFIG_LKDTM is not set
--# CONFIG_FAULT_INJECTION is not set
--# CONFIG_WANT_EXTRA_DEBUG_INFORMATION is not set
--# CONFIG_KGDB is not set
--CONFIG_EARLY_PRINTK=y
--CONFIG_DEBUG_STACKOVERFLOW=y
--# CONFIG_DEBUG_STACK_USAGE is not set
--# CONFIG_DEBUG_RODATA is not set
--# CONFIG_4KSTACKS is not set
--CONFIG_X86_FIND_SMP_CONFIG=y
--CONFIG_X86_MPPARSE=y
--CONFIG_DOUBLEFAULT=y
--
--#
--# Linux VServer
--#
--CONFIG_VSERVER_FILESHARING=y
--CONFIG_VSERVER_AUTO_LBACK=y
--CONFIG_VSERVER_AUTO_SINGLE=y
--CONFIG_VSERVER_COWBL=y
--# CONFIG_VSERVER_VTIME is not set
--# CONFIG_VSERVER_DEVICE is not set
--CONFIG_VSERVER_PROC_SECURE=y
--CONFIG_VSERVER_HARDCPU=y
--CONFIG_VSERVER_IDLETIME=y
--# CONFIG_VSERVER_IDLELIMIT is not set
--# CONFIG_TAGGING_NONE is not set
--# CONFIG_TAGGING_UID16 is not set
--# CONFIG_TAGGING_GID16 is not set
--CONFIG_TAGGING_ID24=y
--# CONFIG_TAGGING_INTERN is not set
--# CONFIG_TAG_NFSD is not set
--# CONFIG_VSERVER_PRIVACY is not set
--CONFIG_VSERVER_CONTEXTS=256
--CONFIG_VSERVER_WARN=y
--# CONFIG_VSERVER_DEBUG is not set
--CONFIG_VSERVER=y
--
--#
--# Security options
--#
--# CONFIG_KEYS is not set
--# CONFIG_SECURITY is not set
--
--#
--# Cryptographic options
--#
--# CONFIG_CRYPTO is not set
--
--#
--# Library routines
--#
--CONFIG_BITREVERSE=y
--CONFIG_CRC_CCITT=y
--CONFIG_CRC16=y
--# CONFIG_CRC_ITU_T is not set
--CONFIG_CRC32=y
--CONFIG_LIBCRC32C=y
--CONFIG_ZLIB_INFLATE=y
--CONFIG_PLIST=y
--CONFIG_HAS_IOMEM=y
--CONFIG_HAS_IOPORT=y
--CONFIG_HAS_DMA=y
--CONFIG_GENERIC_HARDIRQS=y
--CONFIG_GENERIC_IRQ_PROBE=y
--CONFIG_GENERIC_PENDING_IRQ=y
--CONFIG_X86_SMP=y
--CONFIG_X86_HT=y
--CONFIG_X86_BIOS_REBOOT=y
--CONFIG_X86_TRAMPOLINE=y
--CONFIG_KTIME_SCALAR=y
-diff -Nurb linux-2.6.22-590/Documentation/DocBook/Makefile linux-2.6.22-570/Documentation/DocBook/Makefile
---- linux-2.6.22-590/Documentation/DocBook/Makefile 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/Documentation/DocBook/Makefile 2007-07-08 19:32:17.000000000 -0400
+diff -Nurb linux-2.6.22-570/Documentation/DocBook/Makefile linux-2.6.22-590/Documentation/DocBook/Makefile
+--- linux-2.6.22-570/Documentation/DocBook/Makefile 2007-07-08 19:32:17.000000000 -0400
++++ linux-2.6.22-590/Documentation/DocBook/Makefile 2008-01-29 22:12:30.000000000 -0500
@@ -11,7 +11,7 @@
procfs-guide.xml writing_usb_driver.xml \
kernel-api.xml filesystems.xml lsm.xml usb.xml \
gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
-- genericirq.xml kgdb.xml
-+ genericirq.xml
+- genericirq.xml
++ genericirq.xml kgdb.xml
###
# The build process is as follows (targets):
-diff -Nurb linux-2.6.22-590/Documentation/DocBook/kgdb.tmpl linux-2.6.22-570/Documentation/DocBook/kgdb.tmpl
---- linux-2.6.22-590/Documentation/DocBook/kgdb.tmpl 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/Documentation/DocBook/kgdb.tmpl 1969-12-31 19:00:00.000000000 -0500
-@@ -1,250 +0,0 @@
--
--
--
--
--
-- KGDB Internals
--
--
--
-- Tom
-- Rini
--
--
-- trini@kernel.crashing.org
--
--
--
--
--
--
--
-- Amit S.
-- Kale
--
--
-- amitkale@linsyssoft.com
--
--
--
--
--
--
-- 2004-2005
-- MontaVista Software, Inc.
--
--
-- 2004
-- Amit S. Kale
--
--
--
--
-- This file is licensed under the terms of the GNU General Public License
-- version 2. This program is licensed "as is" without any warranty of any
-- kind, whether express or implied.
--
--
--
--
--
--
--
-- Introduction
--
-- kgdb is a source level debugger for linux kernel. It is used along
-- with gdb to debug a linux kernel. Kernel developers can debug a kernel
-- similar to application programs with the use of kgdb. It makes it
-- possible to place breakpoints in kernel code, step through the code
-- and observe variables.
--
--
-- Two machines are required for using kgdb. One of these machines is a
-- development machine and the other is a test machine. The machines are
-- typically connected through a serial line, a null-modem cable which
-- connects their serial ports. It is also possible however, to use an
-- ethernet connection between the machines. The kernel to be debugged
-- runs on the test machine. gdb runs on the development machine. The
-- serial line or ethernet connection is used by gdb to communicate to
-- the kernel being debugged.
--
--
--
-- Compiling a kernel
--
-- To enable CONFIG_KGDB, look under the "Kernel debugging"
-- and then select "KGDB: kernel debugging with remote gdb".
--
--
-- The first choice for I/O is CONFIG_KGDB_ONLY_MODULES.
-- This means that you will only be able to use KGDB after loading a
-- kernel module that defines how you want to be able to talk with
-- KGDB. There are two other choices (more on some architectures) that
-- can be enabled as modules later, if not picked here.
--
-- The first of these is CONFIG_KGDB_8250_NOMODULE.
-- This has sub-options such as CONFIG_KGDB_SIMPLE_SERIAL
-- which toggles choosing the serial port by ttyS number or by specifying
-- a port and IRQ number.
--
--
-- The second of these choices on most systems for I/O is
-- CONFIG_KGDBOE. This requires that the machine to be
-- debugged has an ethernet card which supports the netpoll API, such as
-- the cards supported by CONFIG_E100. There are no
-- sub-options for this, but a kernel command line option is required.
--
--
--
-- Booting the kernel
--
-- The Kernel command line option kgdbwait makes kgdb
-- wait for gdb connection during booting of a kernel. If the
-- CONFIG_KGDB_8250 driver is used (or if applicable,
-- another serial driver) this breakpoint will happen very early on, before
-- console output. If you wish to change serial port information and you
-- have enabled both CONFIG_KGDB_8250 and
-- CONFIG_KGDB_SIMPLE_SERIAL then you must pass the option
-- kgdb8250=<io or mmio>,<address>,<baud
-- rate>,<irq> before kgdbwait.
-- The values io or mmio refer to
-- if the address being passed next needs to be memory mapped
-- (mmio) or not. The address must
-- be passed in hex and is the hardware address and will be remapped if
-- passed as mmio. The value
-- baud rate and irq are base-10.
-- The supported values for baud rate are
-- 9600, 19200,
-- 38400, 57600, and
-- 115200.
--
--
-- To have KGDB stop the kernel and wait, with the compiled values for the
-- serial driver, pass in: kgdbwait.
--
--
-- To specify the values of the SH SCI(F) serial port at boot:
-- kgdbsci=0,115200.
--
--
-- To specify the values of the serial port at boot:
-- kgdb8250=io,3f8,115200,3.
-- On IA64 this could also be:
-- kgdb8250=mmio,0xff5e0000,115200,74
-- And to have KGDB also stop the kernel and wait for GDB to connect, pass in
-- kgdbwait after this arguement.
--
--
-- To configure the CONFIG_KGDBOE driver, pass in
-- kgdboe=[src-port]@<src-ip>/[dev],[tgt-port]@<tgt-ip>/[tgt-macaddr]
-- where:
--
-- src-port (optional): source for UDP packets (defaults to 6443)
-- src-ip: source IP to use (interface address)
-- dev (optional): network interface (eth0)
-- tgt-port (optional): port GDB will use (defaults to 6442)
-- tgt-ip: IP address GDB will be connecting from
-- tgt-macaddr (optional): ethernet MAC address for logging agent (default is broadcast)
--
--
--
-- The CONFIG_KGDBOE driver can be reconfigured at run
-- time, if CONFIG_SYSFS and
-- CONFIG_MODULES by echo'ing a new config string to
-- /sys/module/kgdboe/parameter/kgdboe. The
-- driver can be unconfigured with the special string
-- not_configured.
--
--
--
-- Connecting gdb
--
-- If you have used any of the methods to have KGDB stop and create
-- an initial breakpoint described in the previous chapter, kgdb prints
-- the message "Waiting for connection from remote gdb..." on the console
-- and waits for connection from gdb. At this point you connect gdb to kgdb.
--
--
-- Example (serial):
--
--
-- % gdb ./vmlinux
-- (gdb) set remotebaud 115200
-- (gdb) target remote /dev/ttyS0
--
--
-- Example (ethernet):
--
--
-- % gdb ./vmlinux
-- (gdb) target remote udp:192.168.2.2:6443
--
--
-- Once connected, you can debug a kernel the way you would debug an
-- application program.
--
--
--
-- Architecture specific notes
--
-- SuperH: The NMI switch found on some boards can be used to trigger an
-- initial breakpoint. Subsequent triggers do nothing. If console
-- is enabled on the SCI(F) serial port, and that is the port being used
-- for KGDB, then you must trigger a breakpoint via sysrq, NMI, or
-- some other method prior to connecting, or echo a control-c to the
-- serial port. Also, to use the SCI(F) port for KGDB, the
-- CONFIG_SERIAL_SH_SCI driver must be enabled.
--
--
--
-- The common backend (required)
--
-- There are a few flags which must be set on every architecture in
-- their <asm/kgdb.h> file. These are:
--
--
--
-- NUMREGBYTES: The size in bytes of all of the registers, so
-- that we can ensure they will all fit into a packet.
--
--
-- BUFMAX: The size in bytes of the buffer GDB will read into.
-- This must be larger than NUMREGBYTES.
--
--
-- CACHE_FLUSH_IS_SAFE: Set to one if it always safe to call
-- flush_cache_range or flush_icache_range. On some architectures,
-- these functions may not be safe to call on SMP since we keep other
-- CPUs in a holding pattern.
--
--
--
--
--
-- There are also the following functions for the common backend,
-- found in kernel/kgdb.c that must be supplied by the
-- architecture-specific backend. No weak version of these is provided.
--
--!Iinclude/linux/kgdb.h
--
--
-- The common backend (optional)
--
-- These functions are part of the common backend, found in kernel/kgdb.c
-- and are optionally implemented. Some functions (with _hw_ in the name)
-- end up being required on arches which use hardware breakpoints.
--
--!Ikernel/kgdb.c
--
--
-- Driver-Specific Functions
--
-- Some of the I/O drivers have additional functions that can be
-- called, that are specific to the driver. Calls from other places
-- to these functions must be wrapped in #ifdefs for the driver in
-- question.
--
--!Idrivers/serial/8250_kgdb.c
--
--
-diff -Nurb linux-2.6.22-590/Documentation/accounting/getdelays.c linux-2.6.22-570/Documentation/accounting/getdelays.c
---- linux-2.6.22-590/Documentation/accounting/getdelays.c 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/Documentation/accounting/getdelays.c 2007-07-08 19:32:17.000000000 -0400
-@@ -49,7 +49,6 @@
+diff -Nurb linux-2.6.22-570/Documentation/DocBook/kgdb.tmpl linux-2.6.22-590/Documentation/DocBook/kgdb.tmpl
+--- linux-2.6.22-570/Documentation/DocBook/kgdb.tmpl 1969-12-31 19:00:00.000000000 -0500
++++ linux-2.6.22-590/Documentation/DocBook/kgdb.tmpl 2008-01-29 22:12:30.000000000 -0500
+@@ -0,0 +1,250 @@
++
++
++
++
++
++ KGDB Internals
++
++
++
++ Tom
++ Rini
++
++
++ trini@kernel.crashing.org
++
++
++
++
++
++
++
++ Amit S.
++ Kale
++
++
++ amitkale@linsyssoft.com
++
++
++
++
++
++
++ 2004-2005
++ MontaVista Software, Inc.
++
++
++ 2004
++ Amit S. Kale
++
++
++
++
++ This file is licensed under the terms of the GNU General Public License
++ version 2. This program is licensed "as is" without any warranty of any
++ kind, whether express or implied.
++
++
++
++
++
++
++
++ Introduction
++
++ kgdb is a source level debugger for linux kernel. It is used along
++ with gdb to debug a linux kernel. Kernel developers can debug a kernel
++ similar to application programs with the use of kgdb. It makes it
++ possible to place breakpoints in kernel code, step through the code
++ and observe variables.
++
++
++ Two machines are required for using kgdb. One of these machines is a
++ development machine and the other is a test machine. The machines are
++ typically connected through a serial line, a null-modem cable which
++ connects their serial ports. It is also possible however, to use an
++ ethernet connection between the machines. The kernel to be debugged
++ runs on the test machine. gdb runs on the development machine. The
++ serial line or ethernet connection is used by gdb to communicate to
++ the kernel being debugged.
++
++
++
++ Compiling a kernel
++
++ To enable CONFIG_KGDB, look under the "Kernel debugging"
++ and then select "KGDB: kernel debugging with remote gdb".
++
++
++ The first choice for I/O is CONFIG_KGDB_ONLY_MODULES.
++ This means that you will only be able to use KGDB after loading a
++ kernel module that defines how you want to be able to talk with
++ KGDB. There are two other choices (more on some architectures) that
++ can be enabled as modules later, if not picked here.
++
++ The first of these is CONFIG_KGDB_8250_NOMODULE.
++ This has sub-options such as CONFIG_KGDB_SIMPLE_SERIAL
++ which toggles choosing the serial port by ttyS number or by specifying
++ a port and IRQ number.
++
++
++ The second of these choices on most systems for I/O is
++ CONFIG_KGDBOE. This requires that the machine to be
++ debugged has an ethernet card which supports the netpoll API, such as
++ the cards supported by CONFIG_E100. There are no
++ sub-options for this, but a kernel command line option is required.
++
++
++
++ Booting the kernel
++
++ The Kernel command line option kgdbwait makes kgdb
++ wait for gdb connection during booting of a kernel. If the
++ CONFIG_KGDB_8250 driver is used (or if applicable,
++ another serial driver) this breakpoint will happen very early on, before
++ console output. If you wish to change serial port information and you
++ have enabled both CONFIG_KGDB_8250 and
++ CONFIG_KGDB_SIMPLE_SERIAL then you must pass the option
++ kgdb8250=<io or mmio>,<address>,<baud
++ rate>,<irq> before kgdbwait.
++ The values io or mmio refer to
++ if the address being passed next needs to be memory mapped
++ (mmio) or not. The address must
++ be passed in hex and is the hardware address and will be remapped if
++ passed as mmio. The value
++ baud rate and irq are base-10.
++ The supported values for baud rate are
++ 9600, 19200,
++ 38400, 57600, and
++ 115200.
++
++
++ To have KGDB stop the kernel and wait, with the compiled values for the
++ serial driver, pass in: kgdbwait.
++
++
++ To specify the values of the SH SCI(F) serial port at boot:
++ kgdbsci=0,115200.
++
++
++ To specify the values of the serial port at boot:
++ kgdb8250=io,3f8,115200,3.
++ On IA64 this could also be:
++ kgdb8250=mmio,0xff5e0000,115200,74
++ And to have KGDB also stop the kernel and wait for GDB to connect, pass in
++ kgdbwait after this arguement.
++
++
++ To configure the CONFIG_KGDBOE driver, pass in
++ kgdboe=[src-port]@<src-ip>/[dev],[tgt-port]@<tgt-ip>/[tgt-macaddr]
++ where:
++
++ src-port (optional): source for UDP packets (defaults to 6443)
++ src-ip: source IP to use (interface address)
++ dev (optional): network interface (eth0)
++ tgt-port (optional): port GDB will use (defaults to 6442)
++ tgt-ip: IP address GDB will be connecting from
++ tgt-macaddr (optional): ethernet MAC address for logging agent (default is broadcast)
++
++
++
++ The CONFIG_KGDBOE driver can be reconfigured at run
++ time, if CONFIG_SYSFS and
++ CONFIG_MODULES by echo'ing a new config string to
++ /sys/module/kgdboe/parameter/kgdboe. The
++ driver can be unconfigured with the special string
++ not_configured.
++
++
++
++ Connecting gdb
++
++ If you have used any of the methods to have KGDB stop and create
++ an initial breakpoint described in the previous chapter, kgdb prints
++ the message "Waiting for connection from remote gdb..." on the console
++ and waits for connection from gdb. At this point you connect gdb to kgdb.
++
++
++ Example (serial):
++
++
++ % gdb ./vmlinux
++ (gdb) set remotebaud 115200
++ (gdb) target remote /dev/ttyS0
++
++
++ Example (ethernet):
++
++
++ % gdb ./vmlinux
++ (gdb) target remote udp:192.168.2.2:6443
++
++
++ Once connected, you can debug a kernel the way you would debug an
++ application program.
++
++
++
++ Architecture specific notes
++
++ SuperH: The NMI switch found on some boards can be used to trigger an
++ initial breakpoint. Subsequent triggers do nothing. If console
++ is enabled on the SCI(F) serial port, and that is the port being used
++ for KGDB, then you must trigger a breakpoint via sysrq, NMI, or
++ some other method prior to connecting, or echo a control-c to the
++ serial port. Also, to use the SCI(F) port for KGDB, the
++ CONFIG_SERIAL_SH_SCI driver must be enabled.
++
++
++
++ The common backend (required)
++
++ There are a few flags which must be set on every architecture in
++ their <asm/kgdb.h> file. These are:
++
++
++
++ NUMREGBYTES: The size in bytes of all of the registers, so
++ that we can ensure they will all fit into a packet.
++
++
++ BUFMAX: The size in bytes of the buffer GDB will read into.
++ This must be larger than NUMREGBYTES.
++
++
++ CACHE_FLUSH_IS_SAFE: Set to one if it always safe to call
++ flush_cache_range or flush_icache_range. On some architectures,
++ these functions may not be safe to call on SMP since we keep other
++ CPUs in a holding pattern.
++
++
++
++
++
++ There are also the following functions for the common backend,
++ found in kernel/kgdb.c that must be supplied by the
++ architecture-specific backend. No weak version of these is provided.
++
++!Iinclude/linux/kgdb.h
++
++
++ The common backend (optional)
++
++ These functions are part of the common backend, found in kernel/kgdb.c
++ and are optionally implemented. Some functions (with _hw_ in the name)
++ end up being required on arches which use hardware breakpoints.
++
++!Ikernel/kgdb.c
++
++
++ Driver-Specific Functions
++
++ Some of the I/O drivers have additional functions that can be
++ called, that are specific to the driver. Calls from other places
++ to these functions must be wrapped in #ifdefs for the driver in
++ question.
++
++!Idrivers/serial/8250_kgdb.c
++
++
+diff -Nurb linux-2.6.22-570/Documentation/accounting/getdelays.c linux-2.6.22-590/Documentation/accounting/getdelays.c
+--- linux-2.6.22-570/Documentation/accounting/getdelays.c 2007-07-08 19:32:17.000000000 -0400
++++ linux-2.6.22-590/Documentation/accounting/getdelays.c 2008-01-29 22:12:30.000000000 -0500
+@@ -49,6 +49,7 @@
int dbg;
int print_delays;
int print_io_accounting;
--int print_task_context_switch_counts;
++int print_task_context_switch_counts;
__u64 stime, utime;
#define PRINTF(fmt, arg...) { \
-@@ -196,7 +195,7 @@
+@@ -195,7 +196,7 @@
"IO %15s%15s\n"
" %15llu%15llu\n"
"MEM %15s%15s\n"
-- " %15llu%15llu\n"
-+ " %15llu%15llu\n\n",
+- " %15llu%15llu\n\n",
++ " %15llu%15llu\n"
"count", "real total", "virtual total", "delay total",
t->cpu_count, t->cpu_run_real_total, t->cpu_run_virtual_total,
t->cpu_delay_total,
-@@ -205,14 +204,6 @@
+@@ -204,6 +205,14 @@
"count", "delay total", t->swapin_count, t->swapin_delay_total);
}
--void task_context_switch_counts(struct taskstats *t)
--{
-- printf("\n\nTask %15s%15s\n"
-- " %15lu%15lu\n",
-- "voluntary", "nonvoluntary",
-- t->nvcsw, t->nivcsw);
--}
--
++void task_context_switch_counts(struct taskstats *t)
++{
++ printf("\n\nTask %15s%15s\n"
++ " %15lu%15lu\n",
++ "voluntary", "nonvoluntary",
++ t->nvcsw, t->nivcsw);
++}
++
void print_ioacct(struct taskstats *t)
{
printf("%s: read=%llu, write=%llu, cancelled_write=%llu\n",
-@@ -244,7 +235,7 @@
+@@ -235,7 +244,7 @@
struct msgtemplate msg;
while (1) {
-- c = getopt(argc, argv, "qdiw:r:m:t:p:vl");
-+ c = getopt(argc, argv, "diw:r:m:t:p:vl");
+- c = getopt(argc, argv, "diw:r:m:t:p:vl");
++ c = getopt(argc, argv, "qdiw:r:m:t:p:vl");
if (c < 0)
break;
-@@ -257,10 +248,6 @@
+@@ -248,6 +257,10 @@
printf("printing IO accounting\n");
print_io_accounting = 1;
break;
-- case 'q':
-- printf("printing task/process context switch rates\n");
-- print_task_context_switch_counts = 1;
-- break;
++ case 'q':
++ printf("printing task/process context switch rates\n");
++ print_task_context_switch_counts = 1;
++ break;
case 'w':
logfile = strdup(optarg);
printf("write to file %s\n", logfile);
-@@ -402,8 +389,6 @@
+@@ -389,6 +402,8 @@
print_delayacct((struct taskstats *) NLA_DATA(na));
if (print_io_accounting)
print_ioacct((struct taskstats *) NLA_DATA(na));
-- if (print_task_context_switch_counts)
-- task_context_switch_counts((struct taskstats *) NLA_DATA(na));
++ if (print_task_context_switch_counts)
++ task_context_switch_counts((struct taskstats *) NLA_DATA(na));
if (fd) {
if (write(fd, NLA_DATA(na), na->nla_len) < 0) {
err(1,"write error\n");
-diff -Nurb linux-2.6.22-590/Documentation/accounting/taskstats-struct.txt linux-2.6.22-570/Documentation/accounting/taskstats-struct.txt
---- linux-2.6.22-590/Documentation/accounting/taskstats-struct.txt 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/Documentation/accounting/taskstats-struct.txt 2007-07-08 19:32:17.000000000 -0400
-@@ -22,8 +22,6 @@
+diff -Nurb linux-2.6.22-570/Documentation/accounting/taskstats-struct.txt linux-2.6.22-590/Documentation/accounting/taskstats-struct.txt
+--- linux-2.6.22-570/Documentation/accounting/taskstats-struct.txt 2007-07-08 19:32:17.000000000 -0400
++++ linux-2.6.22-590/Documentation/accounting/taskstats-struct.txt 2008-01-29 22:12:30.000000000 -0500
+@@ -22,6 +22,8 @@
/* Extended accounting fields end */
Their values are collected if CONFIG_TASK_XACCT is set.
--4) Per-task and per-thread context switch count statistics
--
++4) Per-task and per-thread context switch count statistics
++
Future extension should add fields to the end of the taskstats struct, and
should not change the relative position of each field within the struct.
-@@ -160,8 +158,4 @@
+@@ -158,4 +160,8 @@
/* Extended accounting fields end */
--4) Per-task and per-thread statistics
-- __u64 nvcsw; /* Context voluntary switch counter */
-- __u64 nivcsw; /* Context involuntary switch counter */
--
++4) Per-task and per-thread statistics
++ __u64 nvcsw; /* Context voluntary switch counter */
++ __u64 nivcsw; /* Context involuntary switch counter */
++
}
-diff -Nurb linux-2.6.22-590/Documentation/cachetlb.txt linux-2.6.22-570/Documentation/cachetlb.txt
---- linux-2.6.22-590/Documentation/cachetlb.txt 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/Documentation/cachetlb.txt 2007-07-08 19:32:17.000000000 -0400
+diff -Nurb linux-2.6.22-570/Documentation/cachetlb.txt linux-2.6.22-590/Documentation/cachetlb.txt
+--- linux-2.6.22-570/Documentation/cachetlb.txt 2007-07-08 19:32:17.000000000 -0400
++++ linux-2.6.22-590/Documentation/cachetlb.txt 2008-01-29 22:12:30.000000000 -0500
@@ -253,7 +253,7 @@
The first of these two routines is invoked after map_vm_area()
has installed the page table entries. The second is invoked
-- before unmap_kernel_range() deletes the page table entries.
-+ before unmap_vm_area() deletes the page table entries.
+- before unmap_vm_area() deletes the page table entries.
++ before unmap_kernel_range() deletes the page table entries.
There exists another whole class of cpu cache issues which currently
require a whole different set of interfaces to handle properly.
-diff -Nurb linux-2.6.22-590/Documentation/containers.txt linux-2.6.22-570/Documentation/containers.txt
---- linux-2.6.22-590/Documentation/containers.txt 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/Documentation/containers.txt 1969-12-31 19:00:00.000000000 -0500
-@@ -1,543 +0,0 @@
-- CONTAINERS
-- -------
--
--Written by Paul Menage based on Documentation/cpusets.txt
--
--Original copyright statements from cpusets.txt:
--Portions Copyright (C) 2004 BULL SA.
--Portions Copyright (c) 2004-2006 Silicon Graphics, Inc.
--Modified by Paul Jackson
--Modified by Christoph Lameter
--
--CONTENTS:
--=========
--
--1. Containers
-- 1.1 What are containers ?
-- 1.2 Why are containers needed ?
-- 1.3 How are containers implemented ?
-- 1.4 What does notify_on_release do ?
-- 1.5 How do I use containers ?
--2. Usage Examples and Syntax
-- 2.1 Basic Usage
-- 2.2 Attaching processes
--3. Kernel API
-- 3.1 Overview
-- 3.2 Synchronization
-- 3.3 Subsystem API
--4. Questions
--
--1. Containers
--==========
--
--1.1 What are containers ?
------------------------
--
--Containers provide a mechanism for aggregating/partitioning sets of
--tasks, and all their future children, into hierarchical groups with
--specialized behaviour.
--
--Definitions:
--
--A *container* associates a set of tasks with a set of parameters for one
--or more subsystems.
--
--A *subsystem* is a module that makes use of the task grouping
--facilities provided by containers to treat groups of tasks in
--particular ways. A subsystem is typically a "resource controller" that
--schedules a resource or applies per-container limits, but it may be
--anything that wants to act on a group of processes, e.g. a
--virtualization subsystem.
--
--A *hierarchy* is a set of containers arranged in a tree, such that
--every task in the system is in exactly one of the containers in the
--hierarchy, and a set of subsystems; each subsystem has system-specific
--state attached to each container in the hierarchy. Each hierarchy has
--an instance of the container virtual filesystem associated with it.
--
--At any one time there may be multiple active hierachies of task
--containers. Each hierarchy is a partition of all tasks in the system.
--
--User level code may create and destroy containers by name in an
--instance of the container virtual file system, specify and query to
--which container a task is assigned, and list the task pids assigned to
--a container. Those creations and assignments only affect the hierarchy
--associated with that instance of the container file system.
--
--On their own, the only use for containers is for simple job
--tracking. The intention is that other subsystems hook into the generic
--container support to provide new attributes for containers, such as
--accounting/limiting the resources which processes in a container can
--access. For example, cpusets (see Documentation/cpusets.txt) allows
--you to associate a set of CPUs and a set of memory nodes with the
--tasks in each container.
--
--1.2 Why are containers needed ?
------------------------------
--
--There are multiple efforts to provide process aggregations in the
--Linux kernel, mainly for resource tracking purposes. Such efforts
--include cpusets, CKRM/ResGroups, UserBeanCounters, and virtual server
--namespaces. These all require the basic notion of a
--grouping/partitioning of processes, with newly forked processes ending
--in the same group (container) as their parent process.
--
--The kernel container patch provides the minimum essential kernel
--mechanisms required to efficiently implement such groups. It has
--minimal impact on the system fast paths, and provides hooks for
--specific subsystems such as cpusets to provide additional behaviour as
--desired.
--
--Multiple hierarchy support is provided to allow for situations where
--the division of tasks into containers is distinctly different for
--different subsystems - having parallel hierarchies allows each
--hierarchy to be a natural division of tasks, without having to handle
--complex combinations of tasks that would be present if several
--unrelated subsystems needed to be forced into the same tree of
--containers.
--
--At one extreme, each resource controller or subsystem could be in a
--separate hierarchy; at the other extreme, all subsystems
--would be attached to the same hierarchy.
--
--As an example of a scenario (originally proposed by vatsa@in.ibm.com)
--that can benefit from multiple hierarchies, consider a large
--university server with various users - students, professors, system
--tasks etc. The resource planning for this server could be along the
--following lines:
--
-- CPU : Top cpuset
-- / \
-- CPUSet1 CPUSet2
-- | |
-- (Profs) (Students)
--
-- In addition (system tasks) are attached to topcpuset (so
-- that they can run anywhere) with a limit of 20%
--
-- Memory : Professors (50%), students (30%), system (20%)
--
-- Disk : Prof (50%), students (30%), system (20%)
--
-- Network : WWW browsing (20%), Network File System (60%), others (20%)
-- / \
-- Prof (15%) students (5%)
--
--Browsers like firefox/lynx go into the WWW network class, while (k)nfsd go
--into NFS network class.
--
--At the same time firefox/lynx will share an appropriate CPU/Memory class
--depending on who launched it (prof/student).
--
--With the ability to classify tasks differently for different resources
--(by putting those resource subsystems in different hierarchies) then
--the admin can easily set up a script which receives exec notifications
--and depending on who is launching the browser he can
--
-- # echo browser_pid > /mnt///tasks
--
--With only a single hierarchy, he now would potentially have to create
--a separate container for every browser launched and associate it with
--approp network and other resource class. This may lead to
--proliferation of such containers.
--
--Also lets say that the administrator would like to give enhanced network
--access temporarily to a student's browser (since it is night and the user
--wants to do online gaming :) OR give one of the students simulation
--apps enhanced CPU power,
--
--With ability to write pids directly to resource classes, its just a
--matter of :
--
-- # echo pid > /mnt/network//tasks
-- (after some time)
-- # echo pid > /mnt/network//tasks
--
--Without this ability, he would have to split the container into
--multiple separate ones and then associate the new containers with the
--new resource classes.
--
--
--
--1.3 How are containers implemented ?
-----------------------------------
--
--Containers extends the kernel as follows:
--
-- - Each task in the system has a reference-counted pointer to a
-- css_group.
--
-- - A css_group contains a set of reference-counted pointers to
-- container_subsys_state objects, one for each container subsystem
-- registered in the system. There is no direct link from a task to
-- the container of which it's a member in each hierarchy, but this
-- can be determined by following pointers through the
-- container_subsys_state objects. This is because accessing the
-- subsystem state is something that's expected to happen frequently
-- and in performance-critical code, whereas operations that require a
-- task's actual container assignments (in particular, moving between
-- containers) are less common. A linked list runs through the cg_list
-- field of each task_struct using the css_group, anchored at
-- css_group->tasks.
--
-- - A container hierarchy filesystem can be mounted for browsing and
-- manipulation from user space.
--
-- - You can list all the tasks (by pid) attached to any container.
--
--The implementation of containers requires a few, simple hooks
--into the rest of the kernel, none in performance critical paths:
--
-- - in init/main.c, to initialize the root containers and initial
-- css_group at system boot.
--
-- - in fork and exit, to attach and detach a task from its css_group.
--
--In addition a new file system, of type "container" may be mounted, to
--enable browsing and modifying the containers presently known to the
--kernel. When mounting a container hierarchy, you may specify a
--comma-separated list of subsystems to mount as the filesystem mount
--options. By default, mounting the container filesystem attempts to
--mount a hierarchy containing all registered subsystems.
--
--If an active hierarchy with exactly the same set of subsystems already
--exists, it will be reused for the new mount. If no existing hierarchy
--matches, and any of the requested subsystems are in use in an existing
--hierarchy, the mount will fail with -EBUSY. Otherwise, a new hierarchy
--is activated, associated with the requested subsystems.
--
--It's not currently possible to bind a new subsystem to an active
--container hierarchy, or to unbind a subsystem from an active container
--hierarchy. This may be possible in future, but is fraught with nasty
--error-recovery issues.
--
--When a container filesystem is unmounted, if there are any
--subcontainers created below the top-level container, that hierarchy
--will remain active even though unmounted; if there are no
--subcontainers then the hierarchy will be deactivated.
--
--No new system calls are added for containers - all support for
--querying and modifying containers is via this container file system.
+diff -Nurb linux-2.6.22-570/Documentation/containers.txt linux-2.6.22-590/Documentation/containers.txt
+--- linux-2.6.22-570/Documentation/containers.txt 1969-12-31 19:00:00.000000000 -0500
++++ linux-2.6.22-590/Documentation/containers.txt 2008-01-29 22:12:30.000000000 -0500
+@@ -0,0 +1,543 @@
++ CONTAINERS
++ -------
++
++Written by Paul Menage based on Documentation/cpusets.txt
++
++Original copyright statements from cpusets.txt:
++Portions Copyright (C) 2004 BULL SA.
++Portions Copyright (c) 2004-2006 Silicon Graphics, Inc.
++Modified by Paul Jackson
++Modified by Christoph Lameter
++
++CONTENTS:
++=========
++
++1. Containers
++ 1.1 What are containers ?
++ 1.2 Why are containers needed ?
++ 1.3 How are containers implemented ?
++ 1.4 What does notify_on_release do ?
++ 1.5 How do I use containers ?
++2. Usage Examples and Syntax
++ 2.1 Basic Usage
++ 2.2 Attaching processes
++3. Kernel API
++ 3.1 Overview
++ 3.2 Synchronization
++ 3.3 Subsystem API
++4. Questions
++
++1. Containers
++==========
++
++1.1 What are containers ?
++----------------------
++
++Containers provide a mechanism for aggregating/partitioning sets of
++tasks, and all their future children, into hierarchical groups with
++specialized behaviour.
++
++Definitions:
++
++A *container* associates a set of tasks with a set of parameters for one
++or more subsystems.
++
++A *subsystem* is a module that makes use of the task grouping
++facilities provided by containers to treat groups of tasks in
++particular ways. A subsystem is typically a "resource controller" that
++schedules a resource or applies per-container limits, but it may be
++anything that wants to act on a group of processes, e.g. a
++virtualization subsystem.
++
++A *hierarchy* is a set of containers arranged in a tree, such that
++every task in the system is in exactly one of the containers in the
++hierarchy, and a set of subsystems; each subsystem has system-specific
++state attached to each container in the hierarchy. Each hierarchy has
++an instance of the container virtual filesystem associated with it.
++
++At any one time there may be multiple active hierachies of task
++containers. Each hierarchy is a partition of all tasks in the system.
++
++User level code may create and destroy containers by name in an
++instance of the container virtual file system, specify and query to
++which container a task is assigned, and list the task pids assigned to
++a container. Those creations and assignments only affect the hierarchy
++associated with that instance of the container file system.
++
++On their own, the only use for containers is for simple job
++tracking. The intention is that other subsystems hook into the generic
++container support to provide new attributes for containers, such as
++accounting/limiting the resources which processes in a container can
++access. For example, cpusets (see Documentation/cpusets.txt) allows
++you to associate a set of CPUs and a set of memory nodes with the
++tasks in each container.
++
++1.2 Why are containers needed ?
++----------------------------
++
++There are multiple efforts to provide process aggregations in the
++Linux kernel, mainly for resource tracking purposes. Such efforts
++include cpusets, CKRM/ResGroups, UserBeanCounters, and virtual server
++namespaces. These all require the basic notion of a
++grouping/partitioning of processes, with newly forked processes ending
++in the same group (container) as their parent process.
++
++The kernel container patch provides the minimum essential kernel
++mechanisms required to efficiently implement such groups. It has
++minimal impact on the system fast paths, and provides hooks for
++specific subsystems such as cpusets to provide additional behaviour as
++desired.
++
++Multiple hierarchy support is provided to allow for situations where
++the division of tasks into containers is distinctly different for
++different subsystems - having parallel hierarchies allows each
++hierarchy to be a natural division of tasks, without having to handle
++complex combinations of tasks that would be present if several
++unrelated subsystems needed to be forced into the same tree of
++containers.
++
++At one extreme, each resource controller or subsystem could be in a
++separate hierarchy; at the other extreme, all subsystems
++would be attached to the same hierarchy.
++
++As an example of a scenario (originally proposed by vatsa@in.ibm.com)
++that can benefit from multiple hierarchies, consider a large
++university server with various users - students, professors, system
++tasks etc. The resource planning for this server could be along the
++following lines:
++
++ CPU : Top cpuset
++ / \
++ CPUSet1 CPUSet2
++ | |
++ (Profs) (Students)
++
++ In addition (system tasks) are attached to topcpuset (so
++ that they can run anywhere) with a limit of 20%
++
++ Memory : Professors (50%), students (30%), system (20%)
++
++ Disk : Prof (50%), students (30%), system (20%)
++
++ Network : WWW browsing (20%), Network File System (60%), others (20%)
++ / \
++ Prof (15%) students (5%)
++
++Browsers like firefox/lynx go into the WWW network class, while (k)nfsd go
++into NFS network class.
++
++At the same time firefox/lynx will share an appropriate CPU/Memory class
++depending on who launched it (prof/student).
++
++With the ability to classify tasks differently for different resources
++(by putting those resource subsystems in different hierarchies) then
++the admin can easily set up a script which receives exec notifications
++and depending on who is launching the browser he can
++
++ # echo browser_pid > /mnt///tasks
++
++With only a single hierarchy, he now would potentially have to create
++a separate container for every browser launched and associate it with
++approp network and other resource class. This may lead to
++proliferation of such containers.
++
++Also lets say that the administrator would like to give enhanced network
++access temporarily to a student's browser (since it is night and the user
++wants to do online gaming :) OR give one of the students simulation
++apps enhanced CPU power,
++
++With ability to write pids directly to resource classes, its just a
++matter of :
++
++ # echo pid > /mnt/network//tasks
++ (after some time)
++ # echo pid > /mnt/network//tasks
++
++Without this ability, he would have to split the container into
++multiple separate ones and then associate the new containers with the
++new resource classes.
++
++
++
++1.3 How are containers implemented ?
++---------------------------------
++
++Containers extends the kernel as follows:
++
++ - Each task in the system has a reference-counted pointer to a
++ css_group.
++
++ - A css_group contains a set of reference-counted pointers to
++ container_subsys_state objects, one for each container subsystem
++ registered in the system. There is no direct link from a task to
++ the container of which it's a member in each hierarchy, but this
++ can be determined by following pointers through the
++ container_subsys_state objects. This is because accessing the
++ subsystem state is something that's expected to happen frequently
++ and in performance-critical code, whereas operations that require a
++ task's actual container assignments (in particular, moving between
++ containers) are less common. A linked list runs through the cg_list
++ field of each task_struct using the css_group, anchored at
++ css_group->tasks.
++
++ - A container hierarchy filesystem can be mounted for browsing and
++ manipulation from user space.
++
++ - You can list all the tasks (by pid) attached to any container.
++
++The implementation of containers requires a few, simple hooks
++into the rest of the kernel, none in performance critical paths:
++
++ - in init/main.c, to initialize the root containers and initial
++ css_group at system boot.
++
++ - in fork and exit, to attach and detach a task from its css_group.
++
++In addition a new file system, of type "container" may be mounted, to
++enable browsing and modifying the containers presently known to the
++kernel. When mounting a container hierarchy, you may specify a
++comma-separated list of subsystems to mount as the filesystem mount
++options. By default, mounting the container filesystem attempts to
++mount a hierarchy containing all registered subsystems.
++
++If an active hierarchy with exactly the same set of subsystems already
++exists, it will be reused for the new mount. If no existing hierarchy
++matches, and any of the requested subsystems are in use in an existing
++hierarchy, the mount will fail with -EBUSY. Otherwise, a new hierarchy
++is activated, associated with the requested subsystems.
++
++It's not currently possible to bind a new subsystem to an active
++container hierarchy, or to unbind a subsystem from an active container
++hierarchy. This may be possible in future, but is fraught with nasty
++error-recovery issues.
++
++When a container filesystem is unmounted, if there are any
++subcontainers created below the top-level container, that hierarchy
++will remain active even though unmounted; if there are no
++subcontainers then the hierarchy will be deactivated.
++
++No new system calls are added for containers - all support for
++querying and modifying containers is via this container file system.
++
++Each task under /proc has an added file named 'container' displaying,
++for each active hierarchy, the subsystem names and the container name
++as the path relative to the root of the container file system.
++
++Each container is represented by a directory in the container file system
++containing the following files describing that container:
++
++ - tasks: list of tasks (by pid) attached to that container
++ - notify_on_release flag: run /sbin/container_release_agent on exit?
++
++Other subsystems such as cpusets may add additional files in each
++container dir
++
++New containers are created using the mkdir system call or shell
++command. The properties of a container, such as its flags, are
++modified by writing to the appropriate file in that containers
++directory, as listed above.
++
++The named hierarchical structure of nested containers allows partitioning
++a large system into nested, dynamically changeable, "soft-partitions".
++
++The attachment of each task, automatically inherited at fork by any
++children of that task, to a container allows organizing the work load
++on a system into related sets of tasks. A task may be re-attached to
++any other container, if allowed by the permissions on the necessary
++container file system directories.
++
++When a task is moved from one container to another, it gets a new
++css_group pointer - if there's an already existing css_group with the
++desired collection of containers then that group is reused, else a new
++css_group is allocated. Note that the current implementation uses a
++linear search to locate an appropriate existing css_group, so isn't
++very efficient. A future version will use a hash table for better
++performance.
++
++To allow access from a container to the css_groups (and hence tasks)
++that comprise it, a set of cg_container_link objects form a lattice;
++each cg_container_link is linked into a list of cg_container_links for
++a single container on its cont_link_list field, and a list of
++cg_container_links for a single css_group on its cg_link_list.
++
++Thus the set of tasks in a container can be listed by iterating over
++each css_group that references the container, and sub-iterating over
++each css_group's task set.
++
++The use of a Linux virtual file system (vfs) to represent the
++container hierarchy provides for a familiar permission and name space
++for containers, with a minimum of additional kernel code.
++
++1.4 What does notify_on_release do ?
++------------------------------------
++
++*** notify_on_release is disabled in the current patch set. It will be
++*** reactivated in a future patch in a less-intrusive manner
++
++If the notify_on_release flag is enabled (1) in a container, then
++whenever the last task in the container leaves (exits or attaches to
++some other container) and the last child container of that container
++is removed, then the kernel runs the command specified by the contents
++of the "release_agent" file in that hierarchy's root directory,
++supplying the pathname (relative to the mount point of the container
++file system) of the abandoned container. This enables automatic
++removal of abandoned containers. The default value of
++notify_on_release in the root container at system boot is disabled
++(0). The default value of other containers at creation is the current
++value of their parents notify_on_release setting. The default value of
++a container hierarchy's release_agent path is empty.
++
++1.5 How do I use containers ?
++--------------------------
++
++To start a new job that is to be contained within a container, using
++the "cpuset" container subsystem, the steps are something like:
++
++ 1) mkdir /dev/container
++ 2) mount -t container -ocpuset cpuset /dev/container
++ 3) Create the new container by doing mkdir's and write's (or echo's) in
++ the /dev/container virtual file system.
++ 4) Start a task that will be the "founding father" of the new job.
++ 5) Attach that task to the new container by writing its pid to the
++ /dev/container tasks file for that container.
++ 6) fork, exec or clone the job tasks from this founding father task.
++
++For example, the following sequence of commands will setup a container
++named "Charlie", containing just CPUs 2 and 3, and Memory Node 1,
++and then start a subshell 'sh' in that container:
++
++ mount -t container cpuset -ocpuset /dev/container
++ cd /dev/container
++ mkdir Charlie
++ cd Charlie
++ /bin/echo $$ > tasks
++ sh
++ # The subshell 'sh' is now running in container Charlie
++ # The next line should display '/Charlie'
++ cat /proc/self/container
++
++2. Usage Examples and Syntax
++============================
++
++2.1 Basic Usage
++---------------
++
++Creating, modifying, using the containers can be done through the container
++virtual filesystem.
++
++To mount a container hierarchy will all available subsystems, type:
++# mount -t container xxx /dev/container
++
++The "xxx" is not interpreted by the container code, but will appear in
++/proc/mounts so may be any useful identifying string that you like.
++
++To mount a container hierarchy with just the cpuset and numtasks
++subsystems, type:
++# mount -t container -o cpuset,numtasks hier1 /dev/container
++
++To change the set of subsystems bound to a mounted hierarchy, just
++remount with different options:
++
++# mount -o remount,cpuset,ns /dev/container
++
++Note that changing the set of subsystems is currently only supported
++when the hierarchy consists of a single (root) container. Supporting
++the ability to arbitrarily bind/unbind subsystems from an existing
++container hierarchy is intended to be implemented in the future.
++
++Then under /dev/container you can find a tree that corresponds to the
++tree of the containers in the system. For instance, /dev/container
++is the container that holds the whole system.
++
++If you want to create a new container under /dev/container:
++# cd /dev/container
++# mkdir my_container
++
++Now you want to do something with this container.
++# cd my_container
++
++In this directory you can find several files:
++# ls
++notify_on_release release_agent tasks
++(plus whatever files are added by the attached subsystems)
++
++Now attach your shell to this container:
++# /bin/echo $$ > tasks
++
++You can also create containers inside your container by using mkdir in this
++directory.
++# mkdir my_sub_cs
++
++To remove a container, just use rmdir:
++# rmdir my_sub_cs
++
++This will fail if the container is in use (has containers inside, or
++has processes attached, or is held alive by other subsystem-specific
++reference).
++
++2.2 Attaching processes
++-----------------------
++
++# /bin/echo PID > tasks
++
++Note that it is PID, not PIDs. You can only attach ONE task at a time.
++If you have several tasks to attach, you have to do it one after another:
++
++# /bin/echo PID1 > tasks
++# /bin/echo PID2 > tasks
++ ...
++# /bin/echo PIDn > tasks
++
++3. Kernel API
++=============
++
++3.1 Overview
++------------
++
++Each kernel subsystem that wants to hook into the generic container
++system needs to create a container_subsys object. This contains
++various methods, which are callbacks from the container system, along
++with a subsystem id which will be assigned by the container system.
++
++Other fields in the container_subsys object include:
++
++- subsys_id: a unique array index for the subsystem, indicating which
++ entry in container->subsys[] this subsystem should be
++ managing. Initialized by container_register_subsys(); prior to this
++ it should be initialized to -1
++
++- hierarchy: an index indicating which hierarchy, if any, this
++ subsystem is currently attached to. If this is -1, then the
++ subsystem is not attached to any hierarchy, and all tasks should be
++ considered to be members of the subsystem's top_container. It should
++ be initialized to -1.
++
++- name: should be initialized to a unique subsystem name prior to
++ calling container_register_subsystem. Should be no longer than
++ MAX_CONTAINER_TYPE_NAMELEN
++
++Each container object created by the system has an array of pointers,
++indexed by subsystem id; this pointer is entirely managed by the
++subsystem; the generic container code will never touch this pointer.
++
++3.2 Synchronization
++-------------------
++
++There is a global mutex, container_mutex, used by the container
++system. This should be taken by anything that wants to modify a
++container. It may also be taken to prevent containers from being
++modified, but more specific locks may be more appropriate in that
++situation.
++
++See kernel/container.c for more details.
++
++Subsystems can take/release the container_mutex via the functions
++container_lock()/container_unlock(), and can
++take/release the callback_mutex via the functions
++container_lock()/container_unlock().
++
++Accessing a task's container pointer may be done in the following ways:
++- while holding container_mutex
++- while holding the task's alloc_lock (via task_lock())
++- inside an rcu_read_lock() section via rcu_dereference()
++
++3.3 Subsystem API
++--------------------------
++
++Each subsystem should:
++
++- add an entry in linux/container_subsys.h
++- define a container_subsys object called _subsys
++
++Each subsystem may export the following methods. The only mandatory
++methods are create/destroy. Any others that are null are presumed to
++be successful no-ops.
++
++int create(struct container *cont)
++LL=container_mutex
++
++Called to create a subsystem state object for a container. The
++subsystem should set its subsystem pointer for the passed container,
++returning 0 on success or a negative error code. On success, the
++subsystem pointer should point to a structure of type
++container_subsys_state (typically embedded in a larger
++subsystem-specific object), which will be initialized by the container
++system. Note that this will be called at initialization to create the
++root subsystem state for this subsystem; this case can be identified
++by the passed container object having a NULL parent (since it's the
++root of the hierarchy) and may be an appropriate place for
++initialization code.
++
++void destroy(struct container *cont)
++LL=container_mutex
++
++The container system is about to destroy the passed container; the
++subsystem should do any necessary cleanup
++
++int can_attach(struct container_subsys *ss, struct container *cont,
++ struct task_struct *task)
++LL=container_mutex
++
++Called prior to moving a task into a container; if the subsystem
++returns an error, this will abort the attach operation. If a NULL
++task is passed, then a successful result indicates that *any*
++unspecified task can be moved into the container. Note that this isn't
++called on a fork. If this method returns 0 (success) then this should
++remain valid while the caller holds container_mutex.
++
++void attach(struct container_subsys *ss, struct container *cont,
++ struct container *old_cont, struct task_struct *task)
++LL=container_mutex
++
++
++Called after the task has been attached to the container, to allow any
++post-attachment activity that requires memory allocations or blocking.
++
++void fork(struct container_subsy *ss, struct task_struct *task)
++LL=callback_mutex, maybe read_lock(tasklist_lock)
++
++Called when a task is forked into a container. Also called during
++registration for all existing tasks.
++
++void exit(struct container_subsys *ss, struct task_struct *task)
++LL=callback_mutex
++
++Called during task exit
++
++int populate(struct container_subsys *ss, struct container *cont)
++LL=none
++
++Called after creation of a container to allow a subsystem to populate
++the container directory with file entries. The subsystem should make
++calls to container_add_file() with objects of type cftype (see
++include/linux/container.h for details). Note that although this
++method can return an error code, the error code is currently not
++always handled well.
++
++void post_clone(struct container_subsys *ss, struct container *cont)
++
++Called at the end of container_clone() to do any paramater
++initialization which might be required before a task could attach. For
++example in cpusets, no task may attach before 'cpus' and 'mems' are set
++up.
++
++void bind(struct container_subsys *ss, struct container *root)
++LL=callback_mutex
++
++Called when a container subsystem is rebound to a different hierarchy
++and root container. Currently this will only involve movement between
++the default hierarchy (which never has sub-containers) and a hierarchy
++that is being created/destroyed (and hence has no sub-containers).
++
++4. Questions
++============
++
++Q: what's up with this '/bin/echo' ?
++A: bash's builtin 'echo' command does not check calls to write() against
++ errors. If you use it in the container file system, you won't be
++ able to tell whether a command succeeded or failed.
++
++Q: When I attach processes, only the first of the line gets really attached !
++A: We can only return one error code per call to write(). So you should also
++ put only ONE pid.
++
+diff -Nurb linux-2.6.22-570/Documentation/cpuidle/core.txt linux-2.6.22-590/Documentation/cpuidle/core.txt
+--- linux-2.6.22-570/Documentation/cpuidle/core.txt 1969-12-31 19:00:00.000000000 -0500
++++ linux-2.6.22-590/Documentation/cpuidle/core.txt 2008-01-29 22:12:30.000000000 -0500
+@@ -0,0 +1,17 @@
++
++ Supporting multiple CPU idle levels in kernel
++
++ cpuidle
++
++General Information:
++
++Various CPUs today support multiple idle levels that are differentiated
++by varying exit latencies and power consumption during idle.
++cpuidle is a generic in-kernel infrastructure that separates
++idle policy (governor) from idle mechanism (driver) and provides a
++standardized infrastructure to support independent development of
++governors and drivers.
++
++cpuidle resides under /drivers/cpuidle.
++
++
+diff -Nurb linux-2.6.22-570/Documentation/cpuidle/driver.txt linux-2.6.22-590/Documentation/cpuidle/driver.txt
+--- linux-2.6.22-570/Documentation/cpuidle/driver.txt 1969-12-31 19:00:00.000000000 -0500
++++ linux-2.6.22-590/Documentation/cpuidle/driver.txt 2008-01-29 22:12:30.000000000 -0500
+@@ -0,0 +1,24 @@
++
++
++ Supporting multiple CPU idle levels in kernel
++
++ cpuidle drivers
++
++
++
++
++cpuidle driver supports capability detection for a particular system. The
++init and exit routines will be called for each online CPU, with a percpu
++cpuidle_driver object and driver should fill in cpuidle_states inside
++cpuidle_driver depending on the CPU capability.
++
++Driver can handle dynamic state changes (like battery<->AC), by calling
++force_redetect interface.
++
++It is possible to have more than one driver registered at the same time and
++user can switch between drivers using /sysfs interface.
++
++Interfaces:
++int cpuidle_register_driver(struct cpuidle_driver *drv);
++void cpuidle_unregister_driver(struct cpuidle_driver *drv);
++int cpuidle_force_redetect(struct cpuidle_device *dev);
+diff -Nurb linux-2.6.22-570/Documentation/cpuidle/governor.txt linux-2.6.22-590/Documentation/cpuidle/governor.txt
+--- linux-2.6.22-570/Documentation/cpuidle/governor.txt 1969-12-31 19:00:00.000000000 -0500
++++ linux-2.6.22-590/Documentation/cpuidle/governor.txt 2008-01-29 22:12:30.000000000 -0500
+@@ -0,0 +1,24 @@
++
++
++
++ Supporting multiple CPU idle levels in kernel
++
++ cpuidle governors
++
++
++
++
++cpuidle governor is policy routine that decides what idle state to enter at
++any given time. cpuidle core uses different callbacks to governor while
++handling idle entry.
++* select_state callback where governor can determine next idle state to enter
++* prepare_idle callback is called before entering an idle state
++* scan callback is called after a driver forces redetection of the states
++
++More than one governor can be registered at the same time and
++user can switch between drivers using /sysfs interface.
++
++Interfaces:
++int cpuidle_register_governor(struct cpuidle_governor *gov);
++void cpuidle_unregister_governor(struct cpuidle_governor *gov);
++
+diff -Nurb linux-2.6.22-570/Documentation/cpuidle/sysfs.txt linux-2.6.22-590/Documentation/cpuidle/sysfs.txt
+--- linux-2.6.22-570/Documentation/cpuidle/sysfs.txt 1969-12-31 19:00:00.000000000 -0500
++++ linux-2.6.22-590/Documentation/cpuidle/sysfs.txt 2008-01-29 22:12:30.000000000 -0500
+@@ -0,0 +1,27 @@
++
++
++ Supporting multiple CPU idle levels in kernel
++
++ cpuidle sysfs
++
++System global cpuidle information are under
++/sys/devices/system/cpu/cpuidle
++
++The current interfaces in this directory has self-explanatory names:
++* available_drivers
++* available_governors
++* current_driver
++* current_governor
++
++Per logical CPU specific cpuidle information are under
++/sys/devices/system/cpu/cpuX/cpuidle
++for each online cpu X
++
++Under this percpu directory, there is a directory for each idle state supported
++by the driver, which in turn has
++* latency
++* power
++* time
++* usage
++
++
+diff -Nurb linux-2.6.22-570/Documentation/cpusets.txt linux-2.6.22-590/Documentation/cpusets.txt
+--- linux-2.6.22-570/Documentation/cpusets.txt 2007-07-08 19:32:17.000000000 -0400
++++ linux-2.6.22-590/Documentation/cpusets.txt 2008-01-29 22:12:30.000000000 -0500
+@@ -7,6 +7,7 @@
+ Portions Copyright (c) 2004-2006 Silicon Graphics, Inc.
+ Modified by Paul Jackson
+ Modified by Christoph Lameter
++Modified by Paul Menage
+
+ CONTENTS:
+ =========
+@@ -16,10 +17,9 @@
+ 1.2 Why are cpusets needed ?
+ 1.3 How are cpusets implemented ?
+ 1.4 What are exclusive cpusets ?
+- 1.5 What does notify_on_release do ?
+- 1.6 What is memory_pressure ?
+- 1.7 What is memory spread ?
+- 1.8 How do I use cpusets ?
++ 1.5 What is memory_pressure ?
++ 1.6 What is memory spread ?
++ 1.7 How do I use cpusets ?
+ 2. Usage Examples and Syntax
+ 2.1 Basic Usage
+ 2.2 Adding/removing cpus
+@@ -43,18 +43,19 @@
+ hooks, beyond what is already present, required to manage dynamic
+ job placement on large systems.
+
+-Each task has a pointer to a cpuset. Multiple tasks may reference
+-the same cpuset. Requests by a task, using the sched_setaffinity(2)
+-system call to include CPUs in its CPU affinity mask, and using the
+-mbind(2) and set_mempolicy(2) system calls to include Memory Nodes
+-in its memory policy, are both filtered through that tasks cpuset,
+-filtering out any CPUs or Memory Nodes not in that cpuset. The
+-scheduler will not schedule a task on a CPU that is not allowed in
+-its cpus_allowed vector, and the kernel page allocator will not
+-allocate a page on a node that is not allowed in the requesting tasks
+-mems_allowed vector.
++Cpusets use the generic container subsystem described in
++Documentation/container.txt.
+
+-User level code may create and destroy cpusets by name in the cpuset
++Requests by a task, using the sched_setaffinity(2) system call to
++include CPUs in its CPU affinity mask, and using the mbind(2) and
++set_mempolicy(2) system calls to include Memory Nodes in its memory
++policy, are both filtered through that tasks cpuset, filtering out any
++CPUs or Memory Nodes not in that cpuset. The scheduler will not
++schedule a task on a CPU that is not allowed in its cpus_allowed
++vector, and the kernel page allocator will not allocate a page on a
++node that is not allowed in the requesting tasks mems_allowed vector.
++
++User level code may create and destroy cpusets by name in the container
+ virtual file system, manage the attributes and permissions of these
+ cpusets and which CPUs and Memory Nodes are assigned to each cpuset,
+ specify and query to which cpuset a task is assigned, and list the
+@@ -86,9 +87,6 @@
+ and a database), or
+ * NUMA systems running large HPC applications with demanding
+ performance characteristics.
+- * Also cpu_exclusive cpusets are useful for servers running orthogonal
+- workloads such as RT applications requiring low latency and HPC
+- applications that are throughput sensitive
+
+ These subsets, or "soft partitions" must be able to be dynamically
+ adjusted, as the job mix changes, without impacting other concurrently
+@@ -117,7 +115,7 @@
+ - Cpusets are sets of allowed CPUs and Memory Nodes, known to the
+ kernel.
+ - Each task in the system is attached to a cpuset, via a pointer
+- in the task structure to a reference counted cpuset structure.
++ in the task structure to a reference counted container structure.
+ - Calls to sched_setaffinity are filtered to just those CPUs
+ allowed in that tasks cpuset.
+ - Calls to mbind and set_mempolicy are filtered to just
+@@ -131,8 +129,6 @@
+ - A cpuset may be marked exclusive, which ensures that no other
+ cpuset (except direct ancestors and descendents) may contain
+ any overlapping CPUs or Memory Nodes.
+- Also a cpu_exclusive cpuset would be associated with a sched
+- domain.
+ - You can list all the tasks (by pid) attached to any cpuset.
+
+ The implementation of cpusets requires a few, simple hooks
+@@ -144,23 +140,15 @@
+ allowed in that tasks cpuset.
+ - in sched.c migrate_all_tasks(), to keep migrating tasks within
+ the CPUs allowed by their cpuset, if possible.
+- - in sched.c, a new API partition_sched_domains for handling
+- sched domain changes associated with cpu_exclusive cpusets
+- and related changes in both sched.c and arch/ia64/kernel/domain.c
+ - in the mbind and set_mempolicy system calls, to mask the requested
+ Memory Nodes by what's allowed in that tasks cpuset.
+ - in page_alloc.c, to restrict memory to allowed nodes.
+ - in vmscan.c, to restrict page recovery to the current cpuset.
+
+-In addition a new file system, of type "cpuset" may be mounted,
+-typically at /dev/cpuset, to enable browsing and modifying the cpusets
+-presently known to the kernel. No new system calls are added for
+-cpusets - all support for querying and modifying cpusets is via
+-this cpuset file system.
-
--Each task under /proc has an added file named 'container' displaying,
--for each active hierarchy, the subsystem names and the container name
--as the path relative to the root of the container file system.
--
--Each container is represented by a directory in the container file system
--containing the following files describing that container:
--
-- - tasks: list of tasks (by pid) attached to that container
-- - notify_on_release flag: run /sbin/container_release_agent on exit?
--
--Other subsystems such as cpusets may add additional files in each
--container dir
--
--New containers are created using the mkdir system call or shell
--command. The properties of a container, such as its flags, are
--modified by writing to the appropriate file in that containers
--directory, as listed above.
--
--The named hierarchical structure of nested containers allows partitioning
--a large system into nested, dynamically changeable, "soft-partitions".
--
--The attachment of each task, automatically inherited at fork by any
--children of that task, to a container allows organizing the work load
--on a system into related sets of tasks. A task may be re-attached to
--any other container, if allowed by the permissions on the necessary
--container file system directories.
--
--When a task is moved from one container to another, it gets a new
--css_group pointer - if there's an already existing css_group with the
--desired collection of containers then that group is reused, else a new
--css_group is allocated. Note that the current implementation uses a
--linear search to locate an appropriate existing css_group, so isn't
--very efficient. A future version will use a hash table for better
--performance.
--
--To allow access from a container to the css_groups (and hence tasks)
--that comprise it, a set of cg_container_link objects form a lattice;
--each cg_container_link is linked into a list of cg_container_links for
--a single container on its cont_link_list field, and a list of
--cg_container_links for a single css_group on its cg_link_list.
--
--Thus the set of tasks in a container can be listed by iterating over
--each css_group that references the container, and sub-iterating over
--each css_group's task set.
--
--The use of a Linux virtual file system (vfs) to represent the
--container hierarchy provides for a familiar permission and name space
--for containers, with a minimum of additional kernel code.
--
--1.4 What does notify_on_release do ?
--------------------------------------
--
--*** notify_on_release is disabled in the current patch set. It will be
--*** reactivated in a future patch in a less-intrusive manner
--
--If the notify_on_release flag is enabled (1) in a container, then
--whenever the last task in the container leaves (exits or attaches to
--some other container) and the last child container of that container
--is removed, then the kernel runs the command specified by the contents
--of the "release_agent" file in that hierarchy's root directory,
--supplying the pathname (relative to the mount point of the container
--file system) of the abandoned container. This enables automatic
--removal of abandoned containers. The default value of
--notify_on_release in the root container at system boot is disabled
--(0). The default value of other containers at creation is the current
--value of their parents notify_on_release setting. The default value of
--a container hierarchy's release_agent path is empty.
--
--1.5 How do I use containers ?
----------------------------
--
--To start a new job that is to be contained within a container, using
--the "cpuset" container subsystem, the steps are something like:
--
-- 1) mkdir /dev/container
-- 2) mount -t container -ocpuset cpuset /dev/container
-- 3) Create the new container by doing mkdir's and write's (or echo's) in
-- the /dev/container virtual file system.
-- 4) Start a task that will be the "founding father" of the new job.
-- 5) Attach that task to the new container by writing its pid to the
-- /dev/container tasks file for that container.
-- 6) fork, exec or clone the job tasks from this founding father task.
--
--For example, the following sequence of commands will setup a container
--named "Charlie", containing just CPUs 2 and 3, and Memory Node 1,
--and then start a subshell 'sh' in that container:
--
-- mount -t container cpuset -ocpuset /dev/container
-- cd /dev/container
-- mkdir Charlie
-- cd Charlie
-- /bin/echo $$ > tasks
-- sh
-- # The subshell 'sh' is now running in container Charlie
-- # The next line should display '/Charlie'
-- cat /proc/self/container
--
--2. Usage Examples and Syntax
--============================
--
--2.1 Basic Usage
-----------------
--
--Creating, modifying, using the containers can be done through the container
--virtual filesystem.
--
--To mount a container hierarchy will all available subsystems, type:
--# mount -t container xxx /dev/container
--
--The "xxx" is not interpreted by the container code, but will appear in
--/proc/mounts so may be any useful identifying string that you like.
--
--To mount a container hierarchy with just the cpuset and numtasks
--subsystems, type:
--# mount -t container -o cpuset,numtasks hier1 /dev/container
--
--To change the set of subsystems bound to a mounted hierarchy, just
--remount with different options:
--
--# mount -o remount,cpuset,ns /dev/container
--
--Note that changing the set of subsystems is currently only supported
--when the hierarchy consists of a single (root) container. Supporting
--the ability to arbitrarily bind/unbind subsystems from an existing
--container hierarchy is intended to be implemented in the future.
--
--Then under /dev/container you can find a tree that corresponds to the
--tree of the containers in the system. For instance, /dev/container
--is the container that holds the whole system.
--
--If you want to create a new container under /dev/container:
--# cd /dev/container
--# mkdir my_container
--
--Now you want to do something with this container.
--# cd my_container
--
--In this directory you can find several files:
--# ls
--notify_on_release release_agent tasks
--(plus whatever files are added by the attached subsystems)
--
--Now attach your shell to this container:
--# /bin/echo $$ > tasks
--
--You can also create containers inside your container by using mkdir in this
--directory.
--# mkdir my_sub_cs
--
--To remove a container, just use rmdir:
--# rmdir my_sub_cs
--
--This will fail if the container is in use (has containers inside, or
--has processes attached, or is held alive by other subsystem-specific
--reference).
--
--2.2 Attaching processes
-------------------------
--
--# /bin/echo PID > tasks
--
--Note that it is PID, not PIDs. You can only attach ONE task at a time.
--If you have several tasks to attach, you have to do it one after another:
--
--# /bin/echo PID1 > tasks
--# /bin/echo PID2 > tasks
-- ...
--# /bin/echo PIDn > tasks
--
--3. Kernel API
--=============
--
--3.1 Overview
--------------
--
--Each kernel subsystem that wants to hook into the generic container
--system needs to create a container_subsys object. This contains
--various methods, which are callbacks from the container system, along
--with a subsystem id which will be assigned by the container system.
--
--Other fields in the container_subsys object include:
--
--- subsys_id: a unique array index for the subsystem, indicating which
-- entry in container->subsys[] this subsystem should be
-- managing. Initialized by container_register_subsys(); prior to this
-- it should be initialized to -1
--
--- hierarchy: an index indicating which hierarchy, if any, this
-- subsystem is currently attached to. If this is -1, then the
-- subsystem is not attached to any hierarchy, and all tasks should be
-- considered to be members of the subsystem's top_container. It should
-- be initialized to -1.
--
--- name: should be initialized to a unique subsystem name prior to
-- calling container_register_subsystem. Should be no longer than
-- MAX_CONTAINER_TYPE_NAMELEN
--
--Each container object created by the system has an array of pointers,
--indexed by subsystem id; this pointer is entirely managed by the
--subsystem; the generic container code will never touch this pointer.
--
--3.2 Synchronization
---------------------
--
--There is a global mutex, container_mutex, used by the container
--system. This should be taken by anything that wants to modify a
--container. It may also be taken to prevent containers from being
--modified, but more specific locks may be more appropriate in that
--situation.
--
--See kernel/container.c for more details.
--
--Subsystems can take/release the container_mutex via the functions
--container_lock()/container_unlock(), and can
--take/release the callback_mutex via the functions
--container_lock()/container_unlock().
--
--Accessing a task's container pointer may be done in the following ways:
--- while holding container_mutex
--- while holding the task's alloc_lock (via task_lock())
--- inside an rcu_read_lock() section via rcu_dereference()
--
--3.3 Subsystem API
----------------------------
--
--Each subsystem should:
--
--- add an entry in linux/container_subsys.h
--- define a container_subsys object called _subsys
--
--Each subsystem may export the following methods. The only mandatory
--methods are create/destroy. Any others that are null are presumed to
--be successful no-ops.
--
--int create(struct container *cont)
--LL=container_mutex
--
--Called to create a subsystem state object for a container. The
--subsystem should set its subsystem pointer for the passed container,
--returning 0 on success or a negative error code. On success, the
--subsystem pointer should point to a structure of type
--container_subsys_state (typically embedded in a larger
--subsystem-specific object), which will be initialized by the container
--system. Note that this will be called at initialization to create the
--root subsystem state for this subsystem; this case can be identified
--by the passed container object having a NULL parent (since it's the
--root of the hierarchy) and may be an appropriate place for
--initialization code.
--
--void destroy(struct container *cont)
--LL=container_mutex
--
--The container system is about to destroy the passed container; the
--subsystem should do any necessary cleanup
--
--int can_attach(struct container_subsys *ss, struct container *cont,
-- struct task_struct *task)
--LL=container_mutex
--
--Called prior to moving a task into a container; if the subsystem
--returns an error, this will abort the attach operation. If a NULL
--task is passed, then a successful result indicates that *any*
--unspecified task can be moved into the container. Note that this isn't
--called on a fork. If this method returns 0 (success) then this should
--remain valid while the caller holds container_mutex.
--
--void attach(struct container_subsys *ss, struct container *cont,
-- struct container *old_cont, struct task_struct *task)
--LL=container_mutex
--
--
--Called after the task has been attached to the container, to allow any
--post-attachment activity that requires memory allocations or blocking.
--
--void fork(struct container_subsy *ss, struct task_struct *task)
--LL=callback_mutex, maybe read_lock(tasklist_lock)
--
--Called when a task is forked into a container. Also called during
--registration for all existing tasks.
--
--void exit(struct container_subsys *ss, struct task_struct *task)
--LL=callback_mutex
--
--Called during task exit
--
--int populate(struct container_subsys *ss, struct container *cont)
--LL=none
--
--Called after creation of a container to allow a subsystem to populate
--the container directory with file entries. The subsystem should make
--calls to container_add_file() with objects of type cftype (see
--include/linux/container.h for details). Note that although this
--method can return an error code, the error code is currently not
--always handled well.
--
--void post_clone(struct container_subsys *ss, struct container *cont)
--
--Called at the end of container_clone() to do any paramater
--initialization which might be required before a task could attach. For
--example in cpusets, no task may attach before 'cpus' and 'mems' are set
--up.
--
--void bind(struct container_subsys *ss, struct container *root)
--LL=callback_mutex
--
--Called when a container subsystem is rebound to a different hierarchy
--and root container. Currently this will only involve movement between
--the default hierarchy (which never has sub-containers) and a hierarchy
--that is being created/destroyed (and hence has no sub-containers).
--
--4. Questions
--============
--
--Q: what's up with this '/bin/echo' ?
--A: bash's builtin 'echo' command does not check calls to write() against
-- errors. If you use it in the container file system, you won't be
-- able to tell whether a command succeeded or failed.
--
--Q: When I attach processes, only the first of the line gets really attached !
--A: We can only return one error code per call to write(). So you should also
-- put only ONE pid.
--
-diff -Nurb linux-2.6.22-590/Documentation/cpuidle/core.txt linux-2.6.22-570/Documentation/cpuidle/core.txt
---- linux-2.6.22-590/Documentation/cpuidle/core.txt 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/Documentation/cpuidle/core.txt 1969-12-31 19:00:00.000000000 -0500
-@@ -1,17 +0,0 @@
--
-- Supporting multiple CPU idle levels in kernel
--
-- cpuidle
--
--General Information:
--
--Various CPUs today support multiple idle levels that are differentiated
--by varying exit latencies and power consumption during idle.
--cpuidle is a generic in-kernel infrastructure that separates
--idle policy (governor) from idle mechanism (driver) and provides a
--standardized infrastructure to support independent development of
--governors and drivers.
--
--cpuidle resides under /drivers/cpuidle.
--
--
-diff -Nurb linux-2.6.22-590/Documentation/cpuidle/driver.txt linux-2.6.22-570/Documentation/cpuidle/driver.txt
---- linux-2.6.22-590/Documentation/cpuidle/driver.txt 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/Documentation/cpuidle/driver.txt 1969-12-31 19:00:00.000000000 -0500
-@@ -1,24 +0,0 @@
--
--
-- Supporting multiple CPU idle levels in kernel
--
-- cpuidle drivers
--
--
--
--
--cpuidle driver supports capability detection for a particular system. The
--init and exit routines will be called for each online CPU, with a percpu
--cpuidle_driver object and driver should fill in cpuidle_states inside
--cpuidle_driver depending on the CPU capability.
--
--Driver can handle dynamic state changes (like battery<->AC), by calling
--force_redetect interface.
--
--It is possible to have more than one driver registered at the same time and
--user can switch between drivers using /sysfs interface.
--
--Interfaces:
--int cpuidle_register_driver(struct cpuidle_driver *drv);
--void cpuidle_unregister_driver(struct cpuidle_driver *drv);
--int cpuidle_force_redetect(struct cpuidle_device *dev);
-diff -Nurb linux-2.6.22-590/Documentation/cpuidle/governor.txt linux-2.6.22-570/Documentation/cpuidle/governor.txt
---- linux-2.6.22-590/Documentation/cpuidle/governor.txt 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/Documentation/cpuidle/governor.txt 1969-12-31 19:00:00.000000000 -0500
-@@ -1,24 +0,0 @@
--
--
--
-- Supporting multiple CPU idle levels in kernel
--
-- cpuidle governors
--
--
--
--
--cpuidle governor is policy routine that decides what idle state to enter at
--any given time. cpuidle core uses different callbacks to governor while
--handling idle entry.
--* select_state callback where governor can determine next idle state to enter
--* prepare_idle callback is called before entering an idle state
--* scan callback is called after a driver forces redetection of the states
--
--More than one governor can be registered at the same time and
--user can switch between drivers using /sysfs interface.
--
--Interfaces:
--int cpuidle_register_governor(struct cpuidle_governor *gov);
--void cpuidle_unregister_governor(struct cpuidle_governor *gov);
--
-diff -Nurb linux-2.6.22-590/Documentation/cpuidle/sysfs.txt linux-2.6.22-570/Documentation/cpuidle/sysfs.txt
---- linux-2.6.22-590/Documentation/cpuidle/sysfs.txt 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/Documentation/cpuidle/sysfs.txt 1969-12-31 19:00:00.000000000 -0500
-@@ -1,27 +0,0 @@
--
--
-- Supporting multiple CPU idle levels in kernel
--
-- cpuidle sysfs
--
--System global cpuidle information are under
--/sys/devices/system/cpu/cpuidle
--
--The current interfaces in this directory has self-explanatory names:
--* available_drivers
--* available_governors
--* current_driver
--* current_governor
--
--Per logical CPU specific cpuidle information are under
--/sys/devices/system/cpu/cpuX/cpuidle
--for each online cpu X
--
--Under this percpu directory, there is a directory for each idle state supported
--by the driver, which in turn has
--* latency
--* power
--* time
--* usage
--
--
-diff -Nurb linux-2.6.22-590/Documentation/cpusets.txt linux-2.6.22-570/Documentation/cpusets.txt
---- linux-2.6.22-590/Documentation/cpusets.txt 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/Documentation/cpusets.txt 2007-07-08 19:32:17.000000000 -0400
-@@ -7,7 +7,6 @@
- Portions Copyright (c) 2004-2006 Silicon Graphics, Inc.
- Modified by Paul Jackson
- Modified by Christoph Lameter
--Modified by Paul Menage
-
- CONTENTS:
- =========
-@@ -17,9 +16,10 @@
- 1.2 Why are cpusets needed ?
- 1.3 How are cpusets implemented ?
- 1.4 What are exclusive cpusets ?
-- 1.5 What is memory_pressure ?
-- 1.6 What is memory spread ?
-- 1.7 How do I use cpusets ?
-+ 1.5 What does notify_on_release do ?
-+ 1.6 What is memory_pressure ?
-+ 1.7 What is memory spread ?
-+ 1.8 How do I use cpusets ?
- 2. Usage Examples and Syntax
- 2.1 Basic Usage
- 2.2 Adding/removing cpus
-@@ -43,19 +43,18 @@
- hooks, beyond what is already present, required to manage dynamic
- job placement on large systems.
-
--Cpusets use the generic container subsystem described in
--Documentation/container.txt.
-+Each task has a pointer to a cpuset. Multiple tasks may reference
-+the same cpuset. Requests by a task, using the sched_setaffinity(2)
-+system call to include CPUs in its CPU affinity mask, and using the
-+mbind(2) and set_mempolicy(2) system calls to include Memory Nodes
-+in its memory policy, are both filtered through that tasks cpuset,
-+filtering out any CPUs or Memory Nodes not in that cpuset. The
-+scheduler will not schedule a task on a CPU that is not allowed in
-+its cpus_allowed vector, and the kernel page allocator will not
-+allocate a page on a node that is not allowed in the requesting tasks
-+mems_allowed vector.
-
--Requests by a task, using the sched_setaffinity(2) system call to
--include CPUs in its CPU affinity mask, and using the mbind(2) and
--set_mempolicy(2) system calls to include Memory Nodes in its memory
--policy, are both filtered through that tasks cpuset, filtering out any
--CPUs or Memory Nodes not in that cpuset. The scheduler will not
--schedule a task on a CPU that is not allowed in its cpus_allowed
--vector, and the kernel page allocator will not allocate a page on a
--node that is not allowed in the requesting tasks mems_allowed vector.
--
--User level code may create and destroy cpusets by name in the container
-+User level code may create and destroy cpusets by name in the cpuset
- virtual file system, manage the attributes and permissions of these
- cpusets and which CPUs and Memory Nodes are assigned to each cpuset,
- specify and query to which cpuset a task is assigned, and list the
-@@ -87,6 +86,9 @@
- and a database), or
- * NUMA systems running large HPC applications with demanding
- performance characteristics.
-+ * Also cpu_exclusive cpusets are useful for servers running orthogonal
-+ workloads such as RT applications requiring low latency and HPC
-+ applications that are throughput sensitive
-
- These subsets, or "soft partitions" must be able to be dynamically
- adjusted, as the job mix changes, without impacting other concurrently
-@@ -115,7 +117,7 @@
- - Cpusets are sets of allowed CPUs and Memory Nodes, known to the
- kernel.
- - Each task in the system is attached to a cpuset, via a pointer
-- in the task structure to a reference counted container structure.
-+ in the task structure to a reference counted cpuset structure.
- - Calls to sched_setaffinity are filtered to just those CPUs
- allowed in that tasks cpuset.
- - Calls to mbind and set_mempolicy are filtered to just
-@@ -129,6 +131,8 @@
- - A cpuset may be marked exclusive, which ensures that no other
- cpuset (except direct ancestors and descendents) may contain
- any overlapping CPUs or Memory Nodes.
-+ Also a cpu_exclusive cpuset would be associated with a sched
-+ domain.
- - You can list all the tasks (by pid) attached to any cpuset.
-
- The implementation of cpusets requires a few, simple hooks
-@@ -140,15 +144,23 @@
- allowed in that tasks cpuset.
- - in sched.c migrate_all_tasks(), to keep migrating tasks within
- the CPUs allowed by their cpuset, if possible.
-+ - in sched.c, a new API partition_sched_domains for handling
-+ sched domain changes associated with cpu_exclusive cpusets
-+ and related changes in both sched.c and arch/ia64/kernel/domain.c
- - in the mbind and set_mempolicy system calls, to mask the requested
- Memory Nodes by what's allowed in that tasks cpuset.
- - in page_alloc.c, to restrict memory to allowed nodes.
- - in vmscan.c, to restrict page recovery to the current cpuset.
-
--You should mount the "container" filesystem type in order to enable
--browsing and modifying the cpusets presently known to the kernel. No
--new system calls are added for cpusets - all support for querying and
--modifying cpusets is via this cpuset file system.
-+In addition a new file system, of type "cpuset" may be mounted,
-+typically at /dev/cpuset, to enable browsing and modifying the cpusets
-+presently known to the kernel. No new system calls are added for
-+cpusets - all support for querying and modifying cpusets is via
-+this cpuset file system.
-+
-+Each task under /proc has an added file named 'cpuset', displaying
-+the cpuset name, as the path relative to the root of the cpuset file
-+system.
+-Each task under /proc has an added file named 'cpuset', displaying
+-the cpuset name, as the path relative to the root of the cpuset file
+-system.
++You should mount the "container" filesystem type in order to enable
++browsing and modifying the cpusets presently known to the kernel. No
++new system calls are added for cpusets - all support for querying and
++modifying cpusets is via this cpuset file system.
The /proc//status file for each task has two added lines,
displaying the tasks cpus_allowed (on which CPUs it may be scheduled)
-@@ -158,15 +170,16 @@
+@@ -170,16 +158,15 @@
Cpus_allowed: ffffffff,ffffffff,ffffffff,ffffffff
Mems_allowed: ffffffff,ffffffff
--Each cpuset is represented by a directory in the container file system
--containing (on top of the standard container files) the following
--files describing that cpuset:
-+Each cpuset is represented by a directory in the cpuset file system
-+containing the following files describing that cpuset:
+-Each cpuset is represented by a directory in the cpuset file system
+-containing the following files describing that cpuset:
++Each cpuset is represented by a directory in the container file system
++containing (on top of the standard container files) the following
++files describing that cpuset:
- cpus: list of CPUs in that cpuset
- mems: list of Memory Nodes in that cpuset
- memory_migrate flag: if set, move pages to cpusets nodes
- cpu_exclusive flag: is cpu placement exclusive?
- mem_exclusive flag: is memory placement exclusive?
-+ - tasks: list of tasks (by pid) attached to that cpuset
-+ - notify_on_release flag: run /sbin/cpuset_release_agent on exit?
+- - tasks: list of tasks (by pid) attached to that cpuset
+- - notify_on_release flag: run /sbin/cpuset_release_agent on exit?
- memory_pressure: measure of how much paging pressure in cpuset
In addition, the root cpuset only has the following file:
-@@ -218,6 +231,15 @@
+@@ -231,15 +218,6 @@
a direct ancestor or descendent, may share any of the same CPUs or
Memory Nodes.
-+A cpuset that is cpu_exclusive has a scheduler (sched) domain
-+associated with it. The sched domain consists of all CPUs in the
-+current cpuset that are not part of any exclusive child cpusets.
-+This ensures that the scheduler load balancing code only balances
-+against the CPUs that are in the sched domain as defined above and
-+not all of the CPUs in the system. This removes any overhead due to
-+load balancing code trying to pull tasks outside of the cpu_exclusive
-+cpuset only to be prevented by the tasks' cpus_allowed mask.
-+
+-A cpuset that is cpu_exclusive has a scheduler (sched) domain
+-associated with it. The sched domain consists of all CPUs in the
+-current cpuset that are not part of any exclusive child cpusets.
+-This ensures that the scheduler load balancing code only balances
+-against the CPUs that are in the sched domain as defined above and
+-not all of the CPUs in the system. This removes any overhead due to
+-load balancing code trying to pull tasks outside of the cpu_exclusive
+-cpuset only to be prevented by the tasks' cpus_allowed mask.
+-
A cpuset that is mem_exclusive restricts kernel allocations for
page, buffer and other data commonly shared by the kernel across
multiple users. All cpusets, whether mem_exclusive or not, restrict
-@@ -231,7 +253,21 @@
+@@ -253,21 +231,7 @@
outside even a mem_exclusive cpuset.
--1.5 What is memory_pressure ?
-+1.5 What does notify_on_release do ?
-+------------------------------------
-+
-+If the notify_on_release flag is enabled (1) in a cpuset, then whenever
-+the last task in the cpuset leaves (exits or attaches to some other
-+cpuset) and the last child cpuset of that cpuset is removed, then
-+the kernel runs the command /sbin/cpuset_release_agent, supplying the
-+pathname (relative to the mount point of the cpuset file system) of the
-+abandoned cpuset. This enables automatic removal of abandoned cpusets.
-+The default value of notify_on_release in the root cpuset at system
-+boot is disabled (0). The default value of other cpusets at creation
-+is the current value of their parents notify_on_release setting.
-+
-+
-+1.6 What is memory_pressure ?
+-1.5 What does notify_on_release do ?
+-------------------------------------
+-
+-If the notify_on_release flag is enabled (1) in a cpuset, then whenever
+-the last task in the cpuset leaves (exits or attaches to some other
+-cpuset) and the last child cpuset of that cpuset is removed, then
+-the kernel runs the command /sbin/cpuset_release_agent, supplying the
+-pathname (relative to the mount point of the cpuset file system) of the
+-abandoned cpuset. This enables automatic removal of abandoned cpusets.
+-The default value of notify_on_release in the root cpuset at system
+-boot is disabled (0). The default value of other cpusets at creation
+-is the current value of their parents notify_on_release setting.
+-
+-
+-1.6 What is memory_pressure ?
++1.5 What is memory_pressure ?
-----------------------------
The memory_pressure of a cpuset provides a simple per-cpuset metric
of the rate that the tasks in a cpuset are attempting to free up in
-@@ -288,7 +324,7 @@
+@@ -324,7 +288,7 @@
times 1000.
--1.6 What is memory spread ?
-+1.7 What is memory spread ?
+-1.7 What is memory spread ?
++1.6 What is memory spread ?
---------------------------
There are two boolean flag files per cpuset that control where the
kernel allocates pages for the file system buffers and related in
-@@ -359,7 +395,7 @@
+@@ -395,7 +359,7 @@
can become very uneven.
--1.7 How do I use cpusets ?
-+1.8 How do I use cpusets ?
+-1.8 How do I use cpusets ?
++1.7 How do I use cpusets ?
--------------------------
In order to minimize the impact of cpusets on critical kernel
-@@ -449,7 +485,7 @@
+@@ -485,7 +449,7 @@
To start a new job that is to be contained within a cpuset, the steps are:
1) mkdir /dev/cpuset
-- 2) mount -t container -ocpuset cpuset /dev/cpuset
-+ 2) mount -t cpuset none /dev/cpuset
+- 2) mount -t cpuset none /dev/cpuset
++ 2) mount -t container -ocpuset cpuset /dev/cpuset
3) Create the new cpuset by doing mkdir's and write's (or echo's) in
the /dev/cpuset virtual file system.
4) Start a task that will be the "founding father" of the new job.
-@@ -461,7 +497,7 @@
+@@ -497,7 +461,7 @@
named "Charlie", containing just CPUs 2 and 3, and Memory Node 1,
and then start a subshell 'sh' in that cpuset:
-- mount -t container -ocpuset cpuset /dev/cpuset
-+ mount -t cpuset none /dev/cpuset
+- mount -t cpuset none /dev/cpuset
++ mount -t container -ocpuset cpuset /dev/cpuset
cd /dev/cpuset
mkdir Charlie
cd Charlie
-@@ -493,7 +529,7 @@
+@@ -529,7 +493,7 @@
virtual filesystem.
To mount it, type:
--# mount -t container -o cpuset cpuset /dev/cpuset
-+# mount -t cpuset none /dev/cpuset
+-# mount -t cpuset none /dev/cpuset
++# mount -t container -o cpuset cpuset /dev/cpuset
Then under /dev/cpuset you can find a tree that corresponds to the
tree of the cpusets in the system. For instance, /dev/cpuset
-@@ -536,18 +572,6 @@
+@@ -572,6 +536,18 @@
This will fail if the cpuset is in use (has cpusets inside, or has
processes attached).
--Note that for legacy reasons, the "cpuset" filesystem exists as a
--wrapper around the container filesystem.
--
--The command
--
--mount -t cpuset X /dev/cpuset
--
--is equivalent to
--
--mount -t container -ocpuset X /dev/cpuset
--echo "/sbin/cpuset_release_agent" > /dev/cpuset/release_agent
--
++Note that for legacy reasons, the "cpuset" filesystem exists as a
++wrapper around the container filesystem.
++
++The command
++
++mount -t cpuset X /dev/cpuset
++
++is equivalent to
++
++mount -t container -ocpuset X /dev/cpuset
++echo "/sbin/cpuset_release_agent" > /dev/cpuset/release_agent
++
2.2 Adding/removing cpus
------------------------
-diff -Nurb linux-2.6.22-590/Documentation/feature-removal-schedule.txt linux-2.6.22-570/Documentation/feature-removal-schedule.txt
---- linux-2.6.22-590/Documentation/feature-removal-schedule.txt 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/Documentation/feature-removal-schedule.txt 2007-07-08 19:32:17.000000000 -0400
-@@ -162,33 +162,6 @@
+diff -Nurb linux-2.6.22-570/Documentation/feature-removal-schedule.txt linux-2.6.22-590/Documentation/feature-removal-schedule.txt
+--- linux-2.6.22-570/Documentation/feature-removal-schedule.txt 2007-07-08 19:32:17.000000000 -0400
++++ linux-2.6.22-590/Documentation/feature-removal-schedule.txt 2008-01-29 22:12:30.000000000 -0500
+@@ -162,6 +162,33 @@
---------------------------
--What: filemap_nopage, filemap_populate
--When: April 2007
--Why: These legacy interfaces no longer have any callers in the kernel and
-- any functionality provided can be provided with filemap_fault. The
-- removal schedule is short because they are a big maintainence burden
-- and have some bugs.
--Who: Nick Piggin
--
-----------------------------
--
--What: vm_ops.populate, install_page
--When: April 2007
--Why: These legacy interfaces no longer have any callers in the kernel and
-- any functionality provided can be provided with vm_ops.fault.
--Who: Nick Piggin
--
-----------------------------
--
--What: vm_ops.nopage
--When: February 2008, provided in-kernel callers have been converted
--Why: This interface is replaced by vm_ops.fault, but it has been around
-- forever, is used by a lot of drivers, and doesn't cost much to
-- maintain.
--Who: Nick Piggin
--
-----------------------------
--
++What: filemap_nopage, filemap_populate
++When: April 2007
++Why: These legacy interfaces no longer have any callers in the kernel and
++ any functionality provided can be provided with filemap_fault. The
++ removal schedule is short because they are a big maintainence burden
++ and have some bugs.
++Who: Nick Piggin
++
++---------------------------
++
++What: vm_ops.populate, install_page
++When: April 2007
++Why: These legacy interfaces no longer have any callers in the kernel and
++ any functionality provided can be provided with vm_ops.fault.
++Who: Nick Piggin
++
++---------------------------
++
++What: vm_ops.nopage
++When: February 2008, provided in-kernel callers have been converted
++Why: This interface is replaced by vm_ops.fault, but it has been around
++ forever, is used by a lot of drivers, and doesn't cost much to
++ maintain.
++Who: Nick Piggin
++
++---------------------------
++
What: Interrupt only SA_* flags
When: September 2007
Why: The interrupt related SA_* flags are replaced by IRQF_* to move them
-@@ -307,6 +280,25 @@
+@@ -280,25 +307,6 @@
---------------------------
-+What: Multipath cached routing support in ipv4
-+When: in 2.6.23
-+Why: Code was merged, then submitter immediately disappeared leaving
-+ us with no maintainer and lots of bugs. The code should not have
-+ been merged in the first place, and many aspects of it's
-+ implementation are blocking more critical core networking
-+ development. It's marked EXPERIMENTAL and no distribution
-+ enables it because it cause obscure crashes due to unfixable bugs
-+ (interfaces don't return errors so memory allocation can't be
-+ handled, calling contexts of these interfaces make handling
-+ errors impossible too because they get called after we've
-+ totally commited to creating a route object, for example).
-+ This problem has existed for years and no forward progress
-+ has ever been made, and nobody steps up to try and salvage
-+ this code, so we're going to finally just get rid of it.
-+Who: David S. Miller
-+
-+---------------------------
-+
+-What: Multipath cached routing support in ipv4
+-When: in 2.6.23
+-Why: Code was merged, then submitter immediately disappeared leaving
+- us with no maintainer and lots of bugs. The code should not have
+- been merged in the first place, and many aspects of it's
+- implementation are blocking more critical core networking
+- development. It's marked EXPERIMENTAL and no distribution
+- enables it because it cause obscure crashes due to unfixable bugs
+- (interfaces don't return errors so memory allocation can't be
+- handled, calling contexts of these interfaces make handling
+- errors impossible too because they get called after we've
+- totally commited to creating a route object, for example).
+- This problem has existed for years and no forward progress
+- has ever been made, and nobody steps up to try and salvage
+- this code, so we're going to finally just get rid of it.
+-Who: David S. Miller
+-
+----------------------------
+-
What: read_dev_chars(), read_conf_data{,_lpm}() (s390 common I/O layer)
When: December 2007
Why: These functions are a leftover from 2.4 times. They have several
-diff -Nurb linux-2.6.22-590/Documentation/filesystems/00-INDEX linux-2.6.22-570/Documentation/filesystems/00-INDEX
---- linux-2.6.22-590/Documentation/filesystems/00-INDEX 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/Documentation/filesystems/00-INDEX 2007-07-08 19:32:17.000000000 -0400
-@@ -84,8 +84,6 @@
+diff -Nurb linux-2.6.22-570/Documentation/filesystems/00-INDEX linux-2.6.22-590/Documentation/filesystems/00-INDEX
+--- linux-2.6.22-570/Documentation/filesystems/00-INDEX 2007-07-08 19:32:17.000000000 -0400
++++ linux-2.6.22-590/Documentation/filesystems/00-INDEX 2008-01-29 22:12:30.000000000 -0500
+@@ -84,6 +84,8 @@
- info and mount options for the UDF filesystem.
ufs.txt
- info on the ufs filesystem.
--unionfs/
-- - info on the unionfs filesystem
++unionfs/
++ - info on the unionfs filesystem
vfat.txt
- info on using the VFAT filesystem used in Windows NT and Windows 95
vfs.txt
-diff -Nurb linux-2.6.22-590/Documentation/filesystems/Locking linux-2.6.22-570/Documentation/filesystems/Locking
---- linux-2.6.22-590/Documentation/filesystems/Locking 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/Documentation/filesystems/Locking 2007-07-08 19:32:17.000000000 -0400
-@@ -510,14 +510,12 @@
+diff -Nurb linux-2.6.22-570/Documentation/filesystems/Locking linux-2.6.22-590/Documentation/filesystems/Locking
+--- linux-2.6.22-570/Documentation/filesystems/Locking 2007-07-08 19:32:17.000000000 -0400
++++ linux-2.6.22-590/Documentation/filesystems/Locking 2008-01-29 22:12:30.000000000 -0500
+@@ -510,12 +510,14 @@
prototypes:
void (*open)(struct vm_area_struct*);
void (*close)(struct vm_area_struct*);
-- struct page *(*fault)(struct vm_area_struct*, struct fault_data *);
++ struct page *(*fault)(struct vm_area_struct*, struct fault_data *);
struct page *(*nopage)(struct vm_area_struct*, unsigned long, int *);
locking rules:
BKL mmap_sem
open: no yes
close: no yes
--fault: no yes
++fault: no yes
nopage: no yes
================================================================================
-diff -Nurb linux-2.6.22-590/Documentation/filesystems/configfs/configfs.txt linux-2.6.22-570/Documentation/filesystems/configfs/configfs.txt
---- linux-2.6.22-590/Documentation/filesystems/configfs/configfs.txt 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/Documentation/filesystems/configfs/configfs.txt 2007-07-08 19:32:17.000000000 -0400
-@@ -238,8 +238,6 @@
+diff -Nurb linux-2.6.22-570/Documentation/filesystems/configfs/configfs.txt linux-2.6.22-590/Documentation/filesystems/configfs/configfs.txt
+--- linux-2.6.22-570/Documentation/filesystems/configfs/configfs.txt 2007-07-08 19:32:17.000000000 -0400
++++ linux-2.6.22-590/Documentation/filesystems/configfs/configfs.txt 2008-01-29 22:12:30.000000000 -0500
+@@ -238,6 +238,8 @@
struct config_group *(*make_group)(struct config_group *group,
const char *name);
int (*commit_item)(struct config_item *item);
-- void (*disconnect_notify)(struct config_group *group,
-- struct config_item *item);
++ void (*disconnect_notify)(struct config_group *group,
++ struct config_item *item);
void (*drop_item)(struct config_group *group,
struct config_item *item);
};
-@@ -270,16 +268,6 @@
+@@ -268,6 +270,16 @@
for the item to actually disappear from the subsystem's usage. But it
is gone from configfs.
--When drop_item() is called, the item's linkage has already been torn
--down. It no longer has a reference on its parent and has no place in
--the item hierarchy. If a client needs to do some cleanup before this
--teardown happens, the subsystem can implement the
--ct_group_ops->disconnect_notify() method. The method is called after
--configfs has removed the item from the filesystem view but before the
--item is removed from its parent group. Like drop_item(),
--disconnect_notify() is void and cannot fail. Client subsystems should
--not drop any references here, as they still must do it in drop_item().
--
++When drop_item() is called, the item's linkage has already been torn
++down. It no longer has a reference on its parent and has no place in
++the item hierarchy. If a client needs to do some cleanup before this
++teardown happens, the subsystem can implement the
++ct_group_ops->disconnect_notify() method. The method is called after
++configfs has removed the item from the filesystem view but before the
++item is removed from its parent group. Like drop_item(),
++disconnect_notify() is void and cannot fail. Client subsystems should
++not drop any references here, as they still must do it in drop_item().
++
A config_group cannot be removed while it still has child items. This
is implemented in the configfs rmdir(2) code. ->drop_item() will not be
called, as the item has not been dropped. rmdir(2) will fail, as the
-@@ -398,33 +386,6 @@
+@@ -386,6 +398,33 @@
rmdir(2). They also are not considered when rmdir(2) on the parent
group is checking for children.
--[Dependant Subsystems]
--
--Sometimes other drivers depend on particular configfs items. For
--example, ocfs2 mounts depend on a heartbeat region item. If that
--region item is removed with rmdir(2), the ocfs2 mount must BUG or go
--readonly. Not happy.
--
--configfs provides two additional API calls: configfs_depend_item() and
--configfs_undepend_item(). A client driver can call
--configfs_depend_item() on an existing item to tell configfs that it is
--depended on. configfs will then return -EBUSY from rmdir(2) for that
--item. When the item is no longer depended on, the client driver calls
--configfs_undepend_item() on it.
--
--These API cannot be called underneath any configfs callbacks, as
--they will conflict. They can block and allocate. A client driver
--probably shouldn't calling them of its own gumption. Rather it should
--be providing an API that external subsystems call.
--
--How does this work? Imagine the ocfs2 mount process. When it mounts,
--it asks for a heartbeat region item. This is done via a call into the
--heartbeat code. Inside the heartbeat code, the region item is looked
--up. Here, the heartbeat code calls configfs_depend_item(). If it
--succeeds, then heartbeat knows the region is safe to give to ocfs2.
--If it fails, it was being torn down anyway, and heartbeat can gracefully
--pass up an error.
--
++[Dependant Subsystems]
++
++Sometimes other drivers depend on particular configfs items. For
++example, ocfs2 mounts depend on a heartbeat region item. If that
++region item is removed with rmdir(2), the ocfs2 mount must BUG or go
++readonly. Not happy.
++
++configfs provides two additional API calls: configfs_depend_item() and
++configfs_undepend_item(). A client driver can call
++configfs_depend_item() on an existing item to tell configfs that it is
++depended on. configfs will then return -EBUSY from rmdir(2) for that
++item. When the item is no longer depended on, the client driver calls
++configfs_undepend_item() on it.
++
++These API cannot be called underneath any configfs callbacks, as
++they will conflict. They can block and allocate. A client driver
++probably shouldn't calling them of its own gumption. Rather it should
++be providing an API that external subsystems call.
++
++How does this work? Imagine the ocfs2 mount process. When it mounts,
++it asks for a heartbeat region item. This is done via a call into the
++heartbeat code. Inside the heartbeat code, the region item is looked
++up. Here, the heartbeat code calls configfs_depend_item(). If it
++succeeds, then heartbeat knows the region is safe to give to ocfs2.
++If it fails, it was being torn down anyway, and heartbeat can gracefully
++pass up an error.
++
[Committable Items]
NOTE: Committable items are currently unimplemented.
-diff -Nurb linux-2.6.22-590/Documentation/filesystems/unionfs/00-INDEX linux-2.6.22-570/Documentation/filesystems/unionfs/00-INDEX
---- linux-2.6.22-590/Documentation/filesystems/unionfs/00-INDEX 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/Documentation/filesystems/unionfs/00-INDEX 1969-12-31 19:00:00.000000000 -0500
-@@ -1,10 +0,0 @@
--00-INDEX
-- - this file.
--concepts.txt
-- - A brief introduction of concepts.
--issues.txt
-- - A summary of known issues with unionfs.
--rename.txt
-- - Information regarding rename operations.
--usage.txt
-- - Usage information and examples.
-diff -Nurb linux-2.6.22-590/Documentation/filesystems/unionfs/concepts.txt linux-2.6.22-570/Documentation/filesystems/unionfs/concepts.txt
---- linux-2.6.22-590/Documentation/filesystems/unionfs/concepts.txt 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/Documentation/filesystems/unionfs/concepts.txt 1969-12-31 19:00:00.000000000 -0500
-@@ -1,75 +0,0 @@
--Unionfs 2.0 CONCEPTS:
--=====================
--
--This file describes the concepts needed by a namespace unification file
--system.
--
--Branch Priority:
--================
--
--Each branch is assigned a unique priority - starting from 0 (highest
--priority). No two branches can have the same priority.
--
--
--Branch Mode:
--============
--
--Each branch is assigned a mode - read-write or read-only. This allows
--directories on media mounted read-write to be used in a read-only manner.
--
--
--Whiteouts:
--==========
--
--A whiteout removes a file name from the namespace. Whiteouts are needed when
--one attempts to remove a file on a read-only branch.
--
--Suppose we have a two-branch union, where branch 0 is read-write and branch
--1 is read-only. And a file 'foo' on branch 1:
--
--./b0/
--./b1/
--./b1/foo
--
--The unified view would simply be:
--
--./union/
--./union/foo
--
--Since 'foo' is stored on a read-only branch, it cannot be removed. A
--whiteout is used to remove the name 'foo' from the unified namespace. Again,
--since branch 1 is read-only, the whiteout cannot be created there. So, we
--try on a higher priority (lower numerically) branch and create the whiteout
--there.
--
--./b0/
--./b0/.wh.foo
--./b1/
--./b1/foo
--
--Later, when Unionfs traverses branches (due to lookup or readdir), it
--eliminate 'foo' from the namespace (as well as the whiteout itself.)
--
--
--Duplicate Elimination:
--======================
--
--It is possible for files on different branches to have the same name.
--Unionfs then has to select which instance of the file to show to the user.
--Given the fact that each branch has a priority associated with it, the
--simplest solution is to take the instance from the highest priority
--(numerically lowest value) and "hide" the others.
--
--
--Copyup:
--=======
--
--When a change is made to the contents of a file's data or meta-data, they
--have to be stored somewhere. The best way is to create a copy of the
--original file on a branch that is writable, and then redirect the write
--though to this copy. The copy must be made on a higher priority branch so
--that lookup and readdir return this newer "version" of the file rather than
--the original (see duplicate elimination).
--
--
--For more information, see .
-diff -Nurb linux-2.6.22-590/Documentation/filesystems/unionfs/issues.txt linux-2.6.22-570/Documentation/filesystems/unionfs/issues.txt
---- linux-2.6.22-590/Documentation/filesystems/unionfs/issues.txt 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/Documentation/filesystems/unionfs/issues.txt 1969-12-31 19:00:00.000000000 -0500
-@@ -1,39 +0,0 @@
--KNOWN Unionfs 2.0 ISSUES:
--=========================
--
--1. The NFS server returns -EACCES for read-only exports, instead of -EROFS.
-- This means we can't reliably detect a read-only NFS export.
--
--2. Modifying a Unionfs branch directly, while the union is mounted, is
-- currently unsupported, because it could cause a cache incoherency between
-- the union layer and the lower file systems (for that reason, Unionfs
-- currently prohibits using branches which overlap with each other, even
-- partially). We have tested Unionfs under such conditions, and fixed any
-- bugs we found (Unionfs comes with an extensive regression test suite).
-- However, it may still be possible that changes made to lower branches
-- directly could cause cache incoherency which, in the worst case, may case
-- an oops.
--
-- Unionfs 2.0 has a temporary workaround for this. You can force Unionfs
-- to increase the superblock generation number, and hence purge all cached
-- Unionfs objects, which would then be re-gotten from the lower branches.
-- This should ensure cache consistency. To increase the generation number,
-- executed the command:
--
-- mount -t unionfs -o remount,incgen none MOUNTPOINT
--
-- Note that the older way of incrementing the generation number using an
-- ioctl, is no longer supported in Unionfs 2.0. Ioctls in general are not
-- encouraged. Plus, an ioctl is per-file concept, whereas the generation
-- number is a per-file-system concept. Worse, such an ioctl requires an
-- open file, which then has to be invalidated by the very nature of the
-- generation number increase (read: the old generation increase ioctl was
-- pretty racy).
--
--3. Unionfs should not use lookup_one_len() on the underlying f/s as it
-- confuses NFS. Currently, unionfs_lookup() passes lookup intents to the
-- lower file-system, this eliminates part of the problem. The remaining
-- calls to lookup_one_len may need to be changed to pass an intent.
--
--
--For more information, see .
-diff -Nurb linux-2.6.22-590/Documentation/filesystems/unionfs/rename.txt linux-2.6.22-570/Documentation/filesystems/unionfs/rename.txt
---- linux-2.6.22-590/Documentation/filesystems/unionfs/rename.txt 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/Documentation/filesystems/unionfs/rename.txt 1969-12-31 19:00:00.000000000 -0500
-@@ -1,31 +0,0 @@
--Rename is a complex beast. The following table shows which rename(2) operations
--should succeed and which should fail.
--
--o: success
--E: error (either unionfs or vfs)
--X: EXDEV
--
--none = file does not exist
--file = file is a file
--dir = file is a empty directory
--child= file is a non-empty directory
--wh = file is a directory containing only whiteouts; this makes it logically
-- empty
--
-- none file dir child wh
--file o o E E E
--dir o E o E o
--child X E X E X
--wh o E o E o
--
--
--Renaming directories:
--=====================
--
--Whenever a empty (either physically or logically) directory is being renamed,
--the following sequence of events should take place:
--
--1) Remove whiteouts from both source and destination directory
--2) Rename source to destination
--3) Make destination opaque to prevent anything under it from showing up
--
-diff -Nurb linux-2.6.22-590/Documentation/filesystems/unionfs/usage.txt linux-2.6.22-570/Documentation/filesystems/unionfs/usage.txt
---- linux-2.6.22-590/Documentation/filesystems/unionfs/usage.txt 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/Documentation/filesystems/unionfs/usage.txt 1969-12-31 19:00:00.000000000 -0500
-@@ -1,90 +0,0 @@
--Unionfs is a stackable unification file system, which can appear to merge
--the contents of several directories (branches), while keeping their physical
--content separate. Unionfs is useful for unified source tree management,
--merged contents of split CD-ROM, merged separate software package
--directories, data grids, and more. Unionfs allows any mix of read-only and
--read-write branches, as well as insertion and deletion of branches anywhere
--in the fan-out. To maintain Unix semantics, Unionfs handles elimination of
--duplicates, partial-error conditions, and more.
--
--# mount -t unionfs -o branch-option[,union-options[,...]] none MOUNTPOINT
--
--The available branch-option for the mount command is:
--
-- dirs=branch[=ro|=rw][:...]
--
--specifies a separated list of which directories compose the union.
--Directories that come earlier in the list have a higher precedence than
--those which come later. Additionally, read-only or read-write permissions of
--the branch can be specified by appending =ro or =rw (default) to each
--directory.
--
--Syntax:
--
-- dirs=/branch1[=ro|=rw]:/branch2[=ro|=rw]:...:/branchN[=ro|=rw]
--
--Example:
--
-- dirs=/writable_branch=rw:/read-only_branch=ro
--
--
--DYNAMIC BRANCH MANAGEMENT AND REMOUNTS
--======================================
--
--You can remount a union and change its overall mode, or reconfigure the
--branches, as follows.
--
--To downgrade a union from read-write to read-only:
--
--# mount -t unionfs -o remount,ro none MOUNTPOINT
--
--To upgrade a union from read-only to read-write:
--
--# mount -t unionfs -o remount,rw none MOUNTPOINT
--
--To delete a branch /foo, regardless where it is in the current union:
--
--# mount -t unionfs -o del=/foo none MOUNTPOINT
--
--To insert (add) a branch /foo before /bar:
--
--# mount -t unionfs -o remount,add=/bar:/foo none MOUNTPOINT
--
--To insert (add) a branch /foo (with the "rw" mode flag) before /bar:
--
--# mount -t unionfs -o remount,add=/bar:/foo=rw none MOUNTPOINT
--
--To insert (add) a branch /foo (in "rw" mode) at the very beginning (i.e., a
--new highest-priority branch), you can use the above syntax, or use a short
--hand version as follows:
--
--# mount -t unionfs -o remount,add=/foo none MOUNTPOINT
--
--To append a branch to the very end (new lowest-priority branch):
--
--# mount -t unionfs -o remount,add=:/foo none MOUNTPOINT
--
--To append a branch to the very end (new lowest-priority branch), in
--read-only mode:
--
--# mount -t unionfs -o remount,add=:/foo:ro none MOUNTPOINT
--
--Finally, to change the mode of one existing branch, say /foo, from read-only
--to read-write, and change /bar from read-write to read-only:
--
--# mount -t unionfs -o remount,mode=/foo=rw,mode=/bar=ro none MOUNTPOINT
--
--
--CACHE CONSISTENCY
--=================
--
--If you modify any file on any of the lower branches directly, while there is
--a Unionfs 2.0 mounted above any of those branches, you should tell Unionfs
--to purge its caches and re-get the objects. To do that, you have to
--increment the generation number of the superblock using the following
--command:
--
--# mount -t unionfs -o remount,incgen none MOUNTPOINT
--
--
--For more information, see .
-diff -Nurb linux-2.6.22-590/Documentation/firmware_class/firmware_sample_firmware_class.c linux-2.6.22-570/Documentation/firmware_class/firmware_sample_firmware_class.c
---- linux-2.6.22-590/Documentation/firmware_class/firmware_sample_firmware_class.c 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/Documentation/firmware_class/firmware_sample_firmware_class.c 2007-07-08 19:32:17.000000000 -0400
-@@ -78,7 +78,6 @@
- firmware_loading_show, firmware_loading_store);
-
- static ssize_t firmware_data_read(struct kobject *kobj,
-- struct bin_attribute *bin_attr,
- char *buffer, loff_t offset, size_t count)
- {
- struct class_device *class_dev = to_class_dev(kobj);
-@@ -89,7 +88,6 @@
- return count;
- }
- static ssize_t firmware_data_write(struct kobject *kobj,
-- struct bin_attribute *bin_attr,
- char *buffer, loff_t offset, size_t count)
- {
- struct class_device *class_dev = to_class_dev(kobj);
-diff -Nurb linux-2.6.22-590/Documentation/power/freezing-of-tasks.txt linux-2.6.22-570/Documentation/power/freezing-of-tasks.txt
---- linux-2.6.22-590/Documentation/power/freezing-of-tasks.txt 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/Documentation/power/freezing-of-tasks.txt 1969-12-31 19:00:00.000000000 -0500
-@@ -1,160 +0,0 @@
--Freezing of tasks
-- (C) 2007 Rafael J. Wysocki , GPL
--
--I. What is the freezing of tasks?
--
--The freezing of tasks is a mechanism by which user space processes and some
--kernel threads are controlled during hibernation or system-wide suspend (on some
--architectures).
--
--II. How does it work?
--
--There are four per-task flags used for that, PF_NOFREEZE, PF_FROZEN, TIF_FREEZE
--and PF_FREEZER_SKIP (the last one is auxiliary). The tasks that have
--PF_NOFREEZE unset (all user space processes and some kernel threads) are
--regarded as 'freezable' and treated in a special way before the system enters a
--suspend state as well as before a hibernation image is created (in what follows
--we only consider hibernation, but the description also applies to suspend).
--
--Namely, as the first step of the hibernation procedure the function
--freeze_processes() (defined in kernel/power/process.c) is called. It executes
--try_to_freeze_tasks() that sets TIF_FREEZE for all of the freezable tasks and
--sends a fake signal to each of them. A task that receives such a signal and has
--TIF_FREEZE set, should react to it by calling the refrigerator() function
--(defined in kernel/power/process.c), which sets the task's PF_FROZEN flag,
--changes its state to TASK_UNINTERRUPTIBLE and makes it loop until PF_FROZEN is
--cleared for it. Then, we say that the task is 'frozen' and therefore the set of
--functions handling this mechanism is called 'the freezer' (these functions are
--defined in kernel/power/process.c and include/linux/freezer.h). User space
--processes are generally frozen before kernel threads.
--
--It is not recommended to call refrigerator() directly. Instead, it is
--recommended to use the try_to_freeze() function (defined in
--include/linux/freezer.h), that checks the task's TIF_FREEZE flag and makes the
--task enter refrigerator() if the flag is set.
--
--For user space processes try_to_freeze() is called automatically from the
--signal-handling code, but the freezable kernel threads need to call it
--explicitly in suitable places. The code to do this may look like the following:
--
-- do {
-- hub_events();
-- wait_event_interruptible(khubd_wait,
-- !list_empty(&hub_event_list));
-- try_to_freeze();
-- } while (!signal_pending(current));
--
--(from drivers/usb/core/hub.c::hub_thread()).
--
--If a freezable kernel thread fails to call try_to_freeze() after the freezer has
--set TIF_FREEZE for it, the freezing of tasks will fail and the entire
--hibernation operation will be cancelled. For this reason, freezable kernel
--threads must call try_to_freeze() somewhere.
--
--After the system memory state has been restored from a hibernation image and
--devices have been reinitialized, the function thaw_processes() is called in
--order to clear the PF_FROZEN flag for each frozen task. Then, the tasks that
--have been frozen leave refrigerator() and continue running.
--
--III. Which kernel threads are freezable?
--
--Kernel threads are not freezable by default. However, a kernel thread may clear
--PF_NOFREEZE for itself by calling set_freezable() (the resetting of PF_NOFREEZE
--directly is strongly discouraged). From this point it is regarded as freezable
--and must call try_to_freeze() in a suitable place.
--
--IV. Why do we do that?
--
--Generally speaking, there is a couple of reasons to use the freezing of tasks:
--
--1. The principal reason is to prevent filesystems from being damaged after
--hibernation. At the moment we have no simple means of checkpointing
--filesystems, so if there are any modifications made to filesystem data and/or
--metadata on disks, we cannot bring them back to the state from before the
--modifications. At the same time each hibernation image contains some
--filesystem-related information that must be consistent with the state of the
--on-disk data and metadata after the system memory state has been restored from
--the image (otherwise the filesystems will be damaged in a nasty way, usually
--making them almost impossible to repair). We therefore freeze tasks that might
--cause the on-disk filesystems' data and metadata to be modified after the
--hibernation image has been created and before the system is finally powered off.
--The majority of these are user space processes, but if any of the kernel threads
--may cause something like this to happen, they have to be freezable.
--
--2. The second reason is to prevent user space processes and some kernel threads
--from interfering with the suspending and resuming of devices. A user space
--process running on a second CPU while we are suspending devices may, for
--example, be troublesome and without the freezing of tasks we would need some
--safeguards against race conditions that might occur in such a case.
--
--Although Linus Torvalds doesn't like the freezing of tasks, he said this in one
--of the discussions on LKML (http://lkml.org/lkml/2007/4/27/608):
--
--"RJW:> Why we freeze tasks at all or why we freeze kernel threads?
--
--Linus: In many ways, 'at all'.
--
--I _do_ realize the IO request queue issues, and that we cannot actually do
--s2ram with some devices in the middle of a DMA. So we want to be able to
--avoid *that*, there's no question about that. And I suspect that stopping
--user threads and then waiting for a sync is practically one of the easier
--ways to do so.
--
--So in practice, the 'at all' may become a 'why freeze kernel threads?' and
--freezing user threads I don't find really objectionable."
--
--Still, there are kernel threads that may want to be freezable. For example, if
--a kernel that belongs to a device driver accesses the device directly, it in
--principle needs to know when the device is suspended, so that it doesn't try to
--access it at that time. However, if the kernel thread is freezable, it will be
--frozen before the driver's .suspend() callback is executed and it will be
--thawed after the driver's .resume() callback has run, so it won't be accessing
--the device while it's suspended.
--
--3. Another reason for freezing tasks is to prevent user space processes from
--realizing that hibernation (or suspend) operation takes place. Ideally, user
--space processes should not notice that such a system-wide operation has occurred
--and should continue running without any problems after the restore (or resume
--from suspend). Unfortunately, in the most general case this is quite difficult
--to achieve without the freezing of tasks. Consider, for example, a process
--that depends on all CPUs being online while it's running. Since we need to
--disable nonboot CPUs during the hibernation, if this process is not frozen, it
--may notice that the number of CPUs has changed and may start to work incorrectly
--because of that.
--
--V. Are there any problems related to the freezing of tasks?
--
--Yes, there are.
--
--First of all, the freezing of kernel threads may be tricky if they depend one
--on another. For example, if kernel thread A waits for a completion (in the
--TASK_UNINTERRUPTIBLE state) that needs to be done by freezable kernel thread B
--and B is frozen in the meantime, then A will be blocked until B is thawed, which
--may be undesirable. That's why kernel threads are not freezable by default.
--
--Second, there are the following two problems related to the freezing of user
--space processes:
--1. Putting processes into an uninterruptible sleep distorts the load average.
--2. Now that we have FUSE, plus the framework for doing device drivers in
--userspace, it gets even more complicated because some userspace processes are
--now doing the sorts of things that kernel threads do
--(https://lists.linux-foundation.org/pipermail/linux-pm/2007-May/012309.html).
--
--The problem 1. seems to be fixable, although it hasn't been fixed so far. The
--other one is more serious, but it seems that we can work around it by using
--hibernation (and suspend) notifiers (in that case, though, we won't be able to
--avoid the realization by the user space processes that the hibernation is taking
--place).
--
--There are also problems that the freezing of tasks tends to expose, although
--they are not directly related to it. For example, if request_firmware() is
--called from a device driver's .resume() routine, it will timeout and eventually
--fail, because the user land process that should respond to the request is frozen
--at this point. So, seemingly, the failure is due to the freezing of tasks.
--Suppose, however, that the firmware file is located on a filesystem accessible
--only through another device that hasn't been resumed yet. In that case,
--request_firmware() will fail regardless of whether or not the freezing of tasks
--is used. Consequently, the problem is not really related to the freezing of
--tasks, since it generally exists anyway. [The solution to this particular
--problem is to keep the firmware in memory after it's loaded for the first time
--and upload if from memory to the device whenever necessary.]
-diff -Nurb linux-2.6.22-590/Documentation/power/kernel_threads.txt linux-2.6.22-570/Documentation/power/kernel_threads.txt
---- linux-2.6.22-590/Documentation/power/kernel_threads.txt 1969-12-31 19:00:00.000000000 -0500
-+++ linux-2.6.22-570/Documentation/power/kernel_threads.txt 2007-07-08 19:32:17.000000000 -0400
-@@ -0,0 +1,40 @@
-+KERNEL THREADS
-+
-+
-+Freezer
-+
-+Upon entering a suspended state the system will freeze all
-+tasks. This is done by delivering pseudosignals. This affects
-+kernel threads, too. To successfully freeze a kernel thread
-+the thread has to check for the pseudosignal and enter the
-+refrigerator. Code to do this looks like this:
-+
-+ do {
-+ hub_events();
-+ wait_event_interruptible(khubd_wait, !list_empty(&hub_event_list));
-+ try_to_freeze();
-+ } while (!signal_pending(current));
-+
-+from drivers/usb/core/hub.c::hub_thread()
-+
-+
-+The Unfreezable
-+
-+Some kernel threads however, must not be frozen. The kernel must
-+be able to finish pending IO operations and later on be able to
-+write the memory image to disk. Kernel threads needed to do IO
-+must stay awake. Such threads must mark themselves unfreezable
-+like this:
-+
-+ /*
-+ * This thread doesn't need any user-level access,
-+ * so get rid of all our resources.
-+ */
-+ daemonize("usb-storage");
-+
-+ current->flags |= PF_NOFREEZE;
-+
-+from drivers/usb/storage/usb.c::usb_stor_control_thread()
+diff -Nurb linux-2.6.22-570/Documentation/filesystems/unionfs/00-INDEX linux-2.6.22-590/Documentation/filesystems/unionfs/00-INDEX
+--- linux-2.6.22-570/Documentation/filesystems/unionfs/00-INDEX 1969-12-31 19:00:00.000000000 -0500
++++ linux-2.6.22-590/Documentation/filesystems/unionfs/00-INDEX 2008-01-29 22:12:30.000000000 -0500
+@@ -0,0 +1,10 @@
++00-INDEX
++ - this file.
++concepts.txt
++ - A brief introduction of concepts.
++issues.txt
++ - A summary of known issues with unionfs.
++rename.txt
++ - Information regarding rename operations.
++usage.txt
++ - Usage information and examples.
+diff -Nurb linux-2.6.22-570/Documentation/filesystems/unionfs/concepts.txt linux-2.6.22-590/Documentation/filesystems/unionfs/concepts.txt
+--- linux-2.6.22-570/Documentation/filesystems/unionfs/concepts.txt 1969-12-31 19:00:00.000000000 -0500
++++ linux-2.6.22-590/Documentation/filesystems/unionfs/concepts.txt 2008-01-29 22:12:30.000000000 -0500
+@@ -0,0 +1,75 @@
++Unionfs 2.0 CONCEPTS:
++=====================
++
++This file describes the concepts needed by a namespace unification file
++system.
+
-+Such drivers are themselves responsible for staying quiet during
-+the actual snapshotting.
-diff -Nurb linux-2.6.22-590/Documentation/power/swsusp.txt linux-2.6.22-570/Documentation/power/swsusp.txt
---- linux-2.6.22-590/Documentation/power/swsusp.txt 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/Documentation/power/swsusp.txt 2007-07-08 19:32:17.000000000 -0400
-@@ -140,11 +140,21 @@
- website, and not to the Linux Kernel Mailing List. We are working
- toward merging suspend2 into the mainline kernel.
-
--Q: What is the freezing of tasks and why are we using it?
-+Q: A kernel thread must voluntarily freeze itself (call 'refrigerator').
-+I found some kernel threads that don't do it, and they don't freeze
-+so the system can't sleep. Is this a known behavior?
++Branch Priority:
++================
+
-+A: All such kernel threads need to be fixed, one by one. Select the
-+place where the thread is safe to be frozen (no kernel semaphores
-+should be held at that point and it must be safe to sleep there), and
-+add:
++Each branch is assigned a unique priority - starting from 0 (highest
++priority). No two branches can have the same priority.
+
-+ try_to_freeze();
+
-+If the thread is needed for writing the image to storage, you should
-+instead set the PF_NOFREEZE process flag when creating the thread (and
-+be very careful).
-
--A: The freezing of tasks is a mechanism by which user space processes and some
--kernel threads are controlled during hibernation or system-wide suspend (on some
--architectures). See freezing-of-tasks.txt for details.
-
- Q: What is the difference between "platform" and "shutdown"?
-
-diff -Nurb linux-2.6.22-590/Documentation/scsi/scsi_fc_transport.txt linux-2.6.22-570/Documentation/scsi/scsi_fc_transport.txt
---- linux-2.6.22-590/Documentation/scsi/scsi_fc_transport.txt 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/Documentation/scsi/scsi_fc_transport.txt 1969-12-31 19:00:00.000000000 -0500
-@@ -1,450 +0,0 @@
-- SCSI FC Tansport
-- =============================================
--
--Date: 4/12/2007
--Kernel Revisions for features:
-- rports : <>
-- vports : 2.6.22 (? TBD)
--
--
--Introduction
--============
--This file documents the features and components of the SCSI FC Transport.
--It also provides documents the API between the transport and FC LLDDs.
--The FC transport can be found at:
-- drivers/scsi/scsi_transport_fc.c
-- include/scsi/scsi_transport_fc.h
-- include/scsi/scsi_netlink_fc.h
--
--This file is found at Documentation/scsi/scsi_fc_transport.txt
--
--
--FC Remote Ports (rports)
--========================================================================
--<< To Be Supplied >>
--
--
--FC Virtual Ports (vports)
--========================================================================
--
--Overview:
---------------------------------
--
-- New FC standards have defined mechanisms which allows for a single physical
-- port to appear on as multiple communication ports. Using the N_Port Id
-- Virtualization (NPIV) mechanism, a point-to-point connection to a Fabric
-- can be assigned more than 1 N_Port_ID. Each N_Port_ID appears as a
-- separate port to other endpoints on the fabric, even though it shares one
-- physical link to the switch for communication. Each N_Port_ID can have a
-- unique view of the fabric based on fabric zoning and array lun-masking
-- (just like a normal non-NPIV adapter). Using the Virtual Fabric (VF)
-- mechanism, adding a fabric header to each frame allows the port to
-- interact with the Fabric Port to join multiple fabrics. The port will
-- obtain an N_Port_ID on each fabric it joins. Each fabric will have its
-- own unique view of endpoints and configuration parameters. NPIV may be
-- used together with VF so that the port can obtain multiple N_Port_IDs
-- on each virtual fabric.
--
-- The FC transport is now recognizing a new object - a vport. A vport is
-- an entity that has a world-wide unique World Wide Port Name (wwpn) and
-- World Wide Node Name (wwnn). The transport also allows for the FC4's to
-- be specified for the vport, with FCP_Initiator being the primary role
-- expected. Once instantiated by one of the above methods, it will have a
-- distinct N_Port_ID and view of fabric endpoints and storage entities.
-- The fc_host associated with the physical adapter will export the ability
-- to create vports. The transport will create the vport object within the
-- Linux device tree, and instruct the fc_host's driver to instantiate the
-- virtual port. Typically, the driver will create a new scsi_host instance
-- on the vport, resulting in a unique namespace for the vport.
-- Thus, whether a FC port is based on a physical port or on a virtual port,
-- each will appear as a unique scsi_host with its own target and lun space.
--
-- Note: At this time, the transport is written to create only NPIV-based
-- vports. However, consideration was given to VF-based vports and it
-- should be a minor change to add support if needed. The remaining
-- discussion will concentrate on NPIV.
--
-- Note: World Wide Name assignment (and uniqueness guarantees) are left
-- up to an administrative entity controling the vport. For example,
-- if vports are to be associated with virtual machines, a XEN mgmt
-- utility would be responsible for creating wwpn/wwnn's for the vport,
-- using it's own naming authority and OUI. (Note: it already does this
-- for virtual MAC addresses).
--
--
--Device Trees and Vport Objects:
---------------------------------
--
-- Today, the device tree typically contains the scsi_host object,
-- with rports and scsi target objects underneath it. Currently the FC
-- transport creates the vport object and places it under the scsi_host
-- object corresponding to the physical adapter. The LLDD will allocate
-- a new scsi_host for the vport and link it's object under the vport.
-- The remainder of the tree under the vports scsi_host is the same
-- as the non-NPIV case. The transport is written currently to easily
-- allow the parent of the vport to be something other than the scsi_host.
-- This could be used in the future to link the object onto a vm-specific
-- device tree. If the vport's parent is not the physical port's scsi_host,
-- a symbolic link to the vport object will be placed in the physical
-- port's scsi_host.
--
-- Here's what to expect in the device tree :
-- The typical Physical Port's Scsi_Host:
-- /sys/devices/.../host17/
-- and it has the typical decendent tree:
-- /sys/devices/.../host17/rport-17:0-0/target17:0:0/17:0:0:0:
-- and then the vport is created on the Physical Port:
-- /sys/devices/.../host17/vport-17:0-0
-- and the vport's Scsi_Host is then created:
-- /sys/devices/.../host17/vport-17:0-0/host18
-- and then the rest of the tree progresses, such as:
-- /sys/devices/.../host17/vport-17:0-0/host18/rport-18:0-0/target18:0:0/18:0:0:0:
--
-- Here's what to expect in the sysfs tree :
-- scsi_hosts:
-- /sys/class/scsi_host/host17 physical port's scsi_host
-- /sys/class/scsi_host/host18 vport's scsi_host
-- fc_hosts:
-- /sys/class/fc_host/host17 physical port's fc_host
-- /sys/class/fc_host/host18 vport's fc_host
-- fc_vports:
-- /sys/class/fc_vports/vport-17:0-0 the vport's fc_vport
-- fc_rports:
-- /sys/class/fc_remote_ports/rport-17:0-0 rport on the physical port
-- /sys/class/fc_remote_ports/rport-18:0-0 rport on the vport
--
--
--Vport Attributes:
---------------------------------
--
-- The new fc_vport class object has the following attributes
--
-- node_name: Read_Only
-- The WWNN of the vport
--
-- port_name: Read_Only
-- The WWPN of the vport
--
-- roles: Read_Only
-- Indicates the FC4 roles enabled on the vport.
--
-- symbolic_name: Read_Write
-- A string, appended to the driver's symbolic port name string, which
-- is registered with the switch to identify the vport. For example,
-- a hypervisor could set this string to "Xen Domain 2 VM 5 Vport 2",
-- and this set of identifiers can be seen on switch management screens
-- to identify the port.
--
-- vport_delete: Write_Only
-- When written with a "1", will tear down the vport.
--
-- vport_disable: Write_Only
-- When written with a "1", will transition the vport to a disabled.
-- state. The vport will still be instantiated with the Linux kernel,
-- but it will not be active on the FC link.
-- When written with a "0", will enable the vport.
--
-- vport_last_state: Read_Only
-- Indicates the previous state of the vport. See the section below on
-- "Vport States".
--
-- vport_state: Read_Only
-- Indicates the state of the vport. See the section below on
-- "Vport States".
--
-- vport_type: Read_Only
-- Reflects the FC mechanism used to create the virtual port.
-- Only NPIV is supported currently.
--
--
-- For the fc_host class object, the following attributes are added for vports:
--
-- max_npiv_vports: Read_Only
-- Indicates the maximum number of NPIV-based vports that the
-- driver/adapter can support on the fc_host.
--
-- npiv_vports_inuse: Read_Only
-- Indicates how many NPIV-based vports have been instantiated on the
-- fc_host.
--
-- vport_create: Write_Only
-- A "simple" create interface to instantiate a vport on an fc_host.
-- A ":" string is written to the attribute. The transport
-- then instantiates the vport object and calls the LLDD to create the
-- vport with the role of FCP_Initiator. Each WWN is specified as 16
-- hex characters and may *not* contain any prefixes (e.g. 0x, x, etc).
--
-- vport_delete: Write_Only
-- A "simple" delete interface to teardown a vport. A ":"
-- string is written to the attribute. The transport will locate the
-- vport on the fc_host with the same WWNs and tear it down. Each WWN
-- is specified as 16 hex characters and may *not* contain any prefixes
-- (e.g. 0x, x, etc).
--
--
--Vport States:
---------------------------------
--
-- Vport instantiation consists of two parts:
-- - Creation with the kernel and LLDD. This means all transport and
-- driver data structures are built up, and device objects created.
-- This is equivalent to a driver "attach" on an adapter, which is
-- independent of the adapter's link state.
-- - Instantiation of the vport on the FC link via ELS traffic, etc.
-- This is equivalent to a "link up" and successfull link initialization.
-- Futher information can be found in the interfaces section below for
-- Vport Creation.
--
-- Once a vport has been instantiated with the kernel/LLDD, a vport state
-- can be reported via the sysfs attribute. The following states exist:
--
-- FC_VPORT_UNKNOWN - Unknown
-- An temporary state, typically set only while the vport is being
-- instantiated with the kernel and LLDD.
--
-- FC_VPORT_ACTIVE - Active
-- The vport has been successfully been created on the FC link.
-- It is fully functional.
--
-- FC_VPORT_DISABLED - Disabled
-- The vport instantiated, but "disabled". The vport is not instantiated
-- on the FC link. This is equivalent to a physical port with the
-- link "down".
--
-- FC_VPORT_LINKDOWN - Linkdown
-- The vport is not operational as the physical link is not operational.
--
-- FC_VPORT_INITIALIZING - Initializing
-- The vport is in the process of instantiating on the FC link.
-- The LLDD will set this state just prior to starting the ELS traffic
-- to create the vport. This state will persist until the vport is
-- successfully created (state becomes FC_VPORT_ACTIVE) or it fails
-- (state is one of the values below). As this state is transitory,
-- it will not be preserved in the "vport_last_state".
--
-- FC_VPORT_NO_FABRIC_SUPP - No Fabric Support
-- The vport is not operational. One of the following conditions were
-- encountered:
-- - The FC topology is not Point-to-Point
-- - The FC port is not connected to an F_Port
-- - The F_Port has indicated that NPIV is not supported.
--
-- FC_VPORT_NO_FABRIC_RSCS - No Fabric Resources
-- The vport is not operational. The Fabric failed FDISC with a status
-- indicating that it does not have sufficient resources to complete
-- the operation.
--
-- FC_VPORT_FABRIC_LOGOUT - Fabric Logout
-- The vport is not operational. The Fabric has LOGO'd the N_Port_ID
-- associated with the vport.
--
-- FC_VPORT_FABRIC_REJ_WWN - Fabric Rejected WWN
-- The vport is not operational. The Fabric failed FDISC with a status
-- indicating that the WWN's are not valid.
--
-- FC_VPORT_FAILED - VPort Failed
-- The vport is not operational. This is a catchall for all other
-- error conditions.
--
--
-- The following state table indicates the different state transitions:
--
-- State Event New State
-- --------------------------------------------------------------------
-- n/a Initialization Unknown
-- Unknown: Link Down Linkdown
-- Link Up & Loop No Fabric Support
-- Link Up & no Fabric No Fabric Support
-- Link Up & FLOGI response No Fabric Support
-- indicates no NPIV support
-- Link Up & FDISC being sent Initializing
-- Disable request Disable
-- Linkdown: Link Up Unknown
-- Initializing: FDISC ACC Active
-- FDISC LS_RJT w/ no resources No Fabric Resources
-- FDISC LS_RJT w/ invalid Fabric Rejected WWN
-- pname or invalid nport_id
-- FDISC LS_RJT failed for Vport Failed
-- other reasons
-- Link Down Linkdown
-- Disable request Disable
-- Disable: Enable request Unknown
-- Active: LOGO received from fabric Fabric Logout
-- Link Down Linkdown
-- Disable request Disable
-- Fabric Logout: Link still up Unknown
--
-- The following 4 error states all have the same transitions:
-- No Fabric Support:
-- No Fabric Resources:
-- Fabric Rejected WWN:
-- Vport Failed:
-- Disable request Disable
-- Link goes down Linkdown
--
--
--Transport <-> LLDD Interfaces :
---------------------------------
--
--Vport support by LLDD:
--
-- The LLDD indicates support for vports by supplying a vport_create()
-- function in the transport template. The presense of this function will
-- cause the creation of the new attributes on the fc_host. As part of
-- the physical port completing its initialization relative to the
-- transport, it should set the max_npiv_vports attribute to indicate the
-- maximum number of vports the driver and/or adapter supports.
--
--
--Vport Creation:
--
-- The LLDD vport_create() syntax is:
--
-- int vport_create(struct fc_vport *vport, bool disable)
--
-- where:
-- vport: Is the newly allocated vport object
-- disable: If "true", the vport is to be created in a disabled stated.
-- If "false", the vport is to be enabled upon creation.
--
-- When a request is made to create a new vport (via sgio/netlink, or the
-- vport_create fc_host attribute), the transport will validate that the LLDD
-- can support another vport (e.g. max_npiv_vports > npiv_vports_inuse).
-- If not, the create request will be failed. If space remains, the transport
-- will increment the vport count, create the vport object, and then call the
-- LLDD's vport_create() function with the newly allocated vport object.
--
-- As mentioned above, vport creation is divided into two parts:
-- - Creation with the kernel and LLDD. This means all transport and
-- driver data structures are built up, and device objects created.
-- This is equivalent to a driver "attach" on an adapter, which is
-- independent of the adapter's link state.
-- - Instantiation of the vport on the FC link via ELS traffic, etc.
-- This is equivalent to a "link up" and successfull link initialization.
--
-- The LLDD's vport_create() function will not synchronously wait for both
-- parts to be fully completed before returning. It must validate that the
-- infrastructure exists to support NPIV, and complete the first part of
-- vport creation (data structure build up) before returning. We do not
-- hinge vport_create() on the link-side operation mainly because:
-- - The link may be down. It is not a failure if it is. It simply
-- means the vport is in an inoperable state until the link comes up.
-- This is consistent with the link bouncing post vport creation.
-- - The vport may be created in a disabled state.
-- - This is consistent with a model where: the vport equates to a
-- FC adapter. The vport_create is synonymous with driver attachment
-- to the adapter, which is independent of link state.
--
-- Note: special error codes have been defined to delineate infrastructure
-- failure cases for quicker resolution.
--
-- The expected behavior for the LLDD's vport_create() function is:
-- - Validate Infrastructure:
-- - If the driver or adapter cannot support another vport, whether
-- due to improper firmware, (a lie about) max_npiv, or a lack of
-- some other resource - return VPCERR_UNSUPPORTED.
-- - If the driver validates the WWN's against those already active on
-- the adapter and detects an overlap - return VPCERR_BAD_WWN.
-- - If the driver detects the topology is loop, non-fabric, or the
-- FLOGI did not support NPIV - return VPCERR_NO_FABRIC_SUPP.
-- - Allocate data structures. If errors are encountered, such as out
-- of memory conditions, return the respective negative Exxx error code.
-- - If the role is FCP Initiator, the LLDD is to :
-- - Call scsi_host_alloc() to allocate a scsi_host for the vport.
-- - Call scsi_add_host(new_shost, &vport->dev) to start the scsi_host
-- and bind it as a child of the vport device.
-- - Initializes the fc_host attribute values.
-- - Kick of further vport state transitions based on the disable flag and
-- link state - and return success (zero).
--
-- LLDD Implementers Notes:
-- - It is suggested that there be a different fc_function_templates for
-- the physical port and the virtual port. The physical port's template
-- would have the vport_create, vport_delete, and vport_disable functions,
-- while the vports would not.
-- - It is suggested that there be different scsi_host_templates
-- for the physical port and virtual port. Likely, there are driver
-- attributes, embedded into the scsi_host_template, that are applicable
-- for the physical port only (link speed, topology setting, etc). This
-- ensures that the attributes are applicable to the respective scsi_host.
--
--
--Vport Disable/Enable:
--
-- The LLDD vport_disable() syntax is:
--
-- int vport_disable(struct fc_vport *vport, bool disable)
--
-- where:
-- vport: Is vport to to be enabled or disabled
-- disable: If "true", the vport is to be disabled.
-- If "false", the vport is to be enabled.
--
-- When a request is made to change the disabled state on a vport, the
-- transport will validate the request against the existing vport state.
-- If the request is to disable and the vport is already disabled, the
-- request will fail. Similarly, if the request is to enable, and the
-- vport is not in a disabled state, the request will fail. If the request
-- is valid for the vport state, the transport will call the LLDD to
-- change the vport's state.
--
-- Within the LLDD, if a vport is disabled, it remains instantiated with
-- the kernel and LLDD, but it is not active or visible on the FC link in
-- any way. (see Vport Creation and the 2 part instantiation discussion).
-- The vport will remain in this state until it is deleted or re-enabled.
-- When enabling a vport, the LLDD reinstantiates the vport on the FC
-- link - essentially restarting the LLDD statemachine (see Vport States
-- above).
--
--
--Vport Deletion:
--
-- The LLDD vport_delete() syntax is:
--
-- int vport_delete(struct fc_vport *vport)
--
-- where:
-- vport: Is vport to delete
--
-- When a request is made to delete a vport (via sgio/netlink, or via the
-- fc_host or fc_vport vport_delete attributes), the transport will call
-- the LLDD to terminate the vport on the FC link, and teardown all other
-- datastructures and references. If the LLDD completes successfully,
-- the transport will teardown the vport objects and complete the vport
-- removal. If the LLDD delete request fails, the vport object will remain,
-- but will be in an indeterminate state.
--
-- Within the LLDD, the normal code paths for a scsi_host teardown should
-- be followed. E.g. If the vport has a FCP Initiator role, the LLDD
-- will call fc_remove_host() for the vports scsi_host, followed by
-- scsi_remove_host() and scsi_host_put() for the vports scsi_host.
--
--
--Other:
-- fc_host port_type attribute:
-- There is a new fc_host port_type value - FC_PORTTYPE_NPIV. This value
-- must be set on all vport-based fc_hosts. Normally, on a physical port,
-- the port_type attribute would be set to NPORT, NLPORT, etc based on the
-- topology type and existence of the fabric. As this is not applicable to
-- a vport, it makes more sense to report the FC mechanism used to create
-- the vport.
--
-- Driver unload:
-- FC drivers are required to call fc_remove_host() prior to calling
-- scsi_remove_host(). This allows the fc_host to tear down all remote
-- ports prior the scsi_host being torn down. The fc_remove_host() call
-- was updated to remove all vports for the fc_host as well.
--
--
--Credits
--=======
--The following people have contributed to this document:
--
--
--
--
--
--
--James Smart
--james.smart@emulex.com
--
-diff -Nurb linux-2.6.22-590/Documentation/sysctl/kernel.txt linux-2.6.22-570/Documentation/sysctl/kernel.txt
---- linux-2.6.22-590/Documentation/sysctl/kernel.txt 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/Documentation/sysctl/kernel.txt 2007-07-08 19:32:17.000000000 -0400
-@@ -29,7 +29,6 @@
- - java-interpreter [ binfmt_java, obsolete ]
- - kstack_depth_to_print [ X86 only ]
- - l2cr [ PPC only ]
--- mmap_min_addr
- - modprobe ==> Documentation/kmod.txt
- - msgmax
- - msgmnb
-@@ -179,19 +178,6 @@
-
- ==============================================================
-
--mmap_min_addr
--
--This file indicates the amount of address space which a user process will be
--restricted from mmaping. Since kernel null dereference bugs could
--accidentally operate based on the information in the first couple of pages of
--memory userspace processes should not be allowed to write to them. By default
--this value is set to 0 and no protections will be enforced by the security
--module. Setting this value to something like 64k will allow the vast majority
--of applications to work correctly and provide defense in depth against future
--potential kernel bugs.
--
--==============================================================
--
- osrelease, ostype & version:
-
- # cat osrelease
-diff -Nurb linux-2.6.22-590/Documentation/sysfs-rules.txt linux-2.6.22-570/Documentation/sysfs-rules.txt
---- linux-2.6.22-590/Documentation/sysfs-rules.txt 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/Documentation/sysfs-rules.txt 1969-12-31 19:00:00.000000000 -0500
-@@ -1,166 +0,0 @@
--Rules on how to access information in the Linux kernel sysfs
--
--The kernel exported sysfs exports internal kernel implementation-details
--and depends on internal kernel structures and layout. It is agreed upon
--by the kernel developers that the Linux kernel does not provide a stable
--internal API. As sysfs is a direct export of kernel internal
--structures, the sysfs interface can not provide a stable interface eighter,
--it may always change along with internal kernel changes.
--
--To minimize the risk of breaking users of sysfs, which are in most cases
--low-level userspace applications, with a new kernel release, the users
--of sysfs must follow some rules to use an as abstract-as-possible way to
--access this filesystem. The current udev and HAL programs already
--implement this and users are encouraged to plug, if possible, into the
--abstractions these programs provide instead of accessing sysfs
--directly.
--
--But if you really do want or need to access sysfs directly, please follow
--the following rules and then your programs should work with future
--versions of the sysfs interface.
--
--- Do not use libsysfs
-- It makes assumptions about sysfs which are not true. Its API does not
-- offer any abstraction, it exposes all the kernel driver-core
-- implementation details in its own API. Therefore it is not better than
-- reading directories and opening the files yourself.
-- Also, it is not actively maintained, in the sense of reflecting the
-- current kernel-development. The goal of providing a stable interface
-- to sysfs has failed, it causes more problems, than it solves. It
-- violates many of the rules in this document.
--
--- sysfs is always at /sys
-- Parsing /proc/mounts is a waste of time. Other mount points are a
-- system configuration bug you should not try to solve. For test cases,
-- possibly support a SYSFS_PATH environment variable to overwrite the
-- applications behavior, but never try to search for sysfs. Never try
-- to mount it, if you are not an early boot script.
--
--- devices are only "devices"
-- There is no such thing like class-, bus-, physical devices,
-- interfaces, and such that you can rely on in userspace. Everything is
-- just simply a "device". Class-, bus-, physical, ... types are just
-- kernel implementation details, which should not be expected by
-- applications that look for devices in sysfs.
--
-- The properties of a device are:
-- o devpath (/devices/pci0000:00/0000:00:1d.1/usb2/2-2/2-2:1.0)
-- - identical to the DEVPATH value in the event sent from the kernel
-- at device creation and removal
-- - the unique key to the device at that point in time
-- - the kernels path to the device-directory without the leading
-- /sys, and always starting with with a slash
-- - all elements of a devpath must be real directories. Symlinks
-- pointing to /sys/devices must always be resolved to their real
-- target, and the target path must be used to access the device.
-- That way the devpath to the device matches the devpath of the
-- kernel used at event time.
-- - using or exposing symlink values as elements in a devpath string
-- is a bug in the application
--
-- o kernel name (sda, tty, 0000:00:1f.2, ...)
-- - a directory name, identical to the last element of the devpath
-- - applications need to handle spaces and characters like '!' in
-- the name
--
-- o subsystem (block, tty, pci, ...)
-- - simple string, never a path or a link
-- - retrieved by reading the "subsystem"-link and using only the
-- last element of the target path
--
-- o driver (tg3, ata_piix, uhci_hcd)
-- - a simple string, which may contain spaces, never a path or a
-- link
-- - it is retrieved by reading the "driver"-link and using only the
-- last element of the target path
-- - devices which do not have "driver"-link, just do not have a
-- driver; copying the driver value in a child device context, is a
-- bug in the application
--
-- o attributes
-- - the files in the device directory or files below a subdirectories
-- of the same device directory
-- - accessing attributes reached by a symlink pointing to another device,
-- like the "device"-link, is a bug in the application
--
-- Everything else is just a kernel driver-core implementation detail,
-- that should not be assumed to be stable across kernel releases.
--
--- Properties of parent devices never belong into a child device.
-- Always look at the parent devices themselves for determining device
-- context properties. If the device 'eth0' or 'sda' does not have a
-- "driver"-link, then this device does not have a driver. Its value is empty.
-- Never copy any property of the parent-device into a child-device. Parent
-- device-properties may change dynamically without any notice to the
-- child device.
--
--- Hierarchy in a single device-tree
-- There is only one valid place in sysfs where hierarchy can be examined
-- and this is below: /sys/devices.
-- It is planned, that all device directories will end up in the tree
-- below this directory.
--
--- Classification by subsystem
-- There are currently three places for classification of devices:
-- /sys/block, /sys/class and /sys/bus. It is planned that these will
-- not contain any device-directories themselves, but only flat lists of
-- symlinks pointing to the unified /sys/devices tree.
-- All three places have completely different rules on how to access
-- device information. It is planned to merge all three
-- classification-directories into one place at /sys/subsystem,
-- following the layout of the bus-directories. All buses and
-- classes, including the converted block-subsystem, will show up
-- there.
-- The devices belonging to a subsystem will create a symlink in the
-- "devices" directory at /sys/subsystem//devices.
--
-- If /sys/subsystem exists, /sys/bus, /sys/class and /sys/block can be
-- ignored. If it does not exist, you have always to scan all three
-- places, as the kernel is free to move a subsystem from one place to
-- the other, as long as the devices are still reachable by the same
-- subsystem name.
--
-- Assuming /sys/class/ and /sys/bus/, or
-- /sys/block and /sys/class/block are not interchangeable, is a bug in
-- the application.
--
--- Block
-- The converted block-subsystem at /sys/class/block, or
-- /sys/subsystem/block will contain the links for disks and partitions
-- at the same level, never in a hierarchy. Assuming the block-subsytem to
-- contain only disks and not partition-devices in the same flat list is
-- a bug in the application.
--
--- "device"-link and :-links
-- Never depend on the "device"-link. The "device"-link is a workaround
-- for the old layout, where class-devices are not created in
-- /sys/devices/ like the bus-devices. If the link-resolving of a
-- device-directory does not end in /sys/devices/, you can use the
-- "device"-link to find the parent devices in /sys/devices/. That is the
-- single valid use of the "device"-link, it must never appear in any
-- path as an element. Assuming the existence of the "device"-link for
-- a device in /sys/devices/ is a bug in the application.
-- Accessing /sys/class/net/eth0/device is a bug in the application.
--
-- Never depend on the class-specific links back to the /sys/class
-- directory. These links are also a workaround for the design mistake
-- that class-devices are not created in /sys/devices. If a device
-- directory does not contain directories for child devices, these links
-- may be used to find the child devices in /sys/class. That is the single
-- valid use of these links, they must never appear in any path as an
-- element. Assuming the existence of these links for devices which are
-- real child device directories in the /sys/devices tree, is a bug in
-- the application.
--
-- It is planned to remove all these links when when all class-device
-- directories live in /sys/devices.
--
--- Position of devices along device chain can change.
-- Never depend on a specific parent device position in the devpath,
-- or the chain of parent devices. The kernel is free to insert devices into
-- the chain. You must always request the parent device you are looking for
-- by its subsystem value. You need to walk up the chain until you find
-- the device that matches the expected subsystem. Depending on a specific
-- position of a parent device, or exposing relative paths, using "../" to
-- access the chain of parents, is a bug in the application.
--
-diff -Nurb linux-2.6.22-590/MAINTAINERS linux-2.6.22-570/MAINTAINERS
---- linux-2.6.22-590/MAINTAINERS 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/MAINTAINERS 2007-07-08 19:32:17.000000000 -0400
-@@ -232,15 +232,15 @@
- S: Supported
-
- ACPI BATTERY DRIVERS
--P: Alexey Starikovskiy
--M: astarikovskiy@suse.de
-+P: Vladimir P. Lebedev
-+M: vladimir.p.lebedev@intel.com
- L: linux-acpi@vger.kernel.org
- W: http://acpi.sourceforge.net/
- S: Supported
-
- ACPI EC DRIVER
- P: Alexey Starikovskiy
--M: astarikovskiy@suse.de
-+M: alexey.y.starikovskiy@linux.intel.com
- L: linux-acpi@vger.kernel.org
- W: http://acpi.sourceforge.net/
- S: Supported
-@@ -2127,15 +2127,6 @@
- L: kexec@lists.infradead.org
- S: Maintained
-
--KGDB
--P: Jason Wessel
--M: jason.wessel@windriver.com
--P: Amit S. Kale
--M: amitkale@linsyssoft.com
--W: http://sourceforge.net/projects/kgdb
--L: kgdb-bugreport@lists.sourceforge.net
--S: Maintained
--
- KPROBES
- P: Prasanna S Panchamukhi
- M: prasanna@in.ibm.com
-@@ -3602,15 +3593,6 @@
- W: http://www.kernel.dk
- S: Maintained
-
--UNIONFS
--P: Erez Zadok
--M: ezk@cs.sunysb.edu
--P: Josef "Jeff" Sipek
--M: jsipek@cs.sunysb.edu
--L: unionfs@filesystems.org
--W: http://unionfs.filesystems.org
--S: Maintained
--
- USB ACM DRIVER
- P: Oliver Neukum
- M: oliver@neukum.name
-diff -Nurb linux-2.6.22-590/Makefile linux-2.6.22-570/Makefile
---- linux-2.6.22-590/Makefile 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/Makefile 2008-01-23 19:16:03.000000000 -0500
-@@ -1,7 +1,7 @@
- VERSION = 2
- PATCHLEVEL = 6
- SUBLEVEL = 22
--EXTRAVERSION = -prep
-+EXTRAVERSION = .14-vs2.3.0.29
- NAME = Holy Dancing Manatees, Batman!
-
- # *DOCUMENTATION*
-@@ -496,11 +496,6 @@
- CFLAGS += -fomit-frame-pointer
- endif
-
--ifdef CONFIG_UNWIND_INFO
--CFLAGS += -fasynchronous-unwind-tables
--LDFLAGS_vmlinux += --eh-frame-hdr
--endif
--
- ifdef CONFIG_DEBUG_INFO
- CFLAGS += -g
- endif
-diff -Nurb linux-2.6.22-590/Makefile.orig linux-2.6.22-570/Makefile.orig
---- linux-2.6.22-590/Makefile.orig 1969-12-31 19:00:00.000000000 -0500
-+++ linux-2.6.22-570/Makefile.orig 2008-01-23 19:15:54.000000000 -0500
-@@ -0,0 +1,1493 @@
-+VERSION = 2
-+PATCHLEVEL = 6
-+SUBLEVEL = 22
-+EXTRAVERSION = .14
-+NAME = Holy Dancing Manatees, Batman!
-+
-+# *DOCUMENTATION*
-+# To see a list of typical targets execute "make help"
-+# More info can be located in ./README
-+# Comments in this file are targeted only to the developer, do not
-+# expect to learn how to build the kernel reading this file.
-+
-+# Do not:
-+# o use make's built-in rules and variables
-+# (this increases performance and avoid hard-to-debug behavour);
-+# o print "Entering directory ...";
-+MAKEFLAGS += -rR --no-print-directory
-+
-+# We are using a recursive build, so we need to do a little thinking
-+# to get the ordering right.
-+#
-+# Most importantly: sub-Makefiles should only ever modify files in
-+# their own directory. If in some directory we have a dependency on
-+# a file in another dir (which doesn't happen often, but it's often
-+# unavoidable when linking the built-in.o targets which finally
-+# turn into vmlinux), we will call a sub make in that other dir, and
-+# after that we are sure that everything which is in that other dir
-+# is now up to date.
-+#
-+# The only cases where we need to modify files which have global
-+# effects are thus separated out and done before the recursive
-+# descending is started. They are now explicitly listed as the
-+# prepare rule.
-+
-+# To put more focus on warnings, be less verbose as default
-+# Use 'make V=1' to see the full commands
-+
-+ifdef V
-+ ifeq ("$(origin V)", "command line")
-+ KBUILD_VERBOSE = $(V)
-+ endif
-+endif
-+ifndef KBUILD_VERBOSE
-+ KBUILD_VERBOSE = 0
-+endif
++Branch Mode:
++============
+
-+# Call a source code checker (by default, "sparse") as part of the
-+# C compilation.
-+#
-+# Use 'make C=1' to enable checking of only re-compiled files.
-+# Use 'make C=2' to enable checking of *all* source files, regardless
-+# of whether they are re-compiled or not.
-+#
-+# See the file "Documentation/sparse.txt" for more details, including
-+# where to get the "sparse" utility.
++Each branch is assigned a mode - read-write or read-only. This allows
++directories on media mounted read-write to be used in a read-only manner.
+
-+ifdef C
-+ ifeq ("$(origin C)", "command line")
-+ KBUILD_CHECKSRC = $(C)
-+ endif
-+endif
-+ifndef KBUILD_CHECKSRC
-+ KBUILD_CHECKSRC = 0
-+endif
+
-+# Use make M=dir to specify directory of external module to build
-+# Old syntax make ... SUBDIRS=$PWD is still supported
-+# Setting the environment variable KBUILD_EXTMOD take precedence
-+ifdef SUBDIRS
-+ KBUILD_EXTMOD ?= $(SUBDIRS)
-+endif
-+ifdef M
-+ ifeq ("$(origin M)", "command line")
-+ KBUILD_EXTMOD := $(M)
-+ endif
-+endif
++Whiteouts:
++==========
+
++A whiteout removes a file name from the namespace. Whiteouts are needed when
++one attempts to remove a file on a read-only branch.
+
-+# kbuild supports saving output files in a separate directory.
-+# To locate output files in a separate directory two syntaxes are supported.
-+# In both cases the working directory must be the root of the kernel src.
-+# 1) O=
-+# Use "make O=dir/to/store/output/files/"
-+#
-+# 2) Set KBUILD_OUTPUT
-+# Set the environment variable KBUILD_OUTPUT to point to the directory
-+# where the output files shall be placed.
-+# export KBUILD_OUTPUT=dir/to/store/output/files/
-+# make
-+#
-+# The O= assignment takes precedence over the KBUILD_OUTPUT environment
-+# variable.
++Suppose we have a two-branch union, where branch 0 is read-write and branch
++1 is read-only. And a file 'foo' on branch 1:
+
++./b0/
++./b1/
++./b1/foo
+
-+# KBUILD_SRC is set on invocation of make in OBJ directory
-+# KBUILD_SRC is not intended to be used by the regular user (for now)
-+ifeq ($(KBUILD_SRC),)
++The unified view would simply be:
+
-+# OK, Make called in directory where kernel src resides
-+# Do we want to locate output files in a separate directory?
-+ifdef O
-+ ifeq ("$(origin O)", "command line")
-+ KBUILD_OUTPUT := $(O)
-+ endif
-+endif
++./union/
++./union/foo
+
-+# That's our default target when none is given on the command line
-+PHONY := _all
-+_all:
-+
-+ifneq ($(KBUILD_OUTPUT),)
-+# Invoke a second make in the output directory, passing relevant variables
-+# check that the output directory actually exists
-+saved-output := $(KBUILD_OUTPUT)
-+KBUILD_OUTPUT := $(shell cd $(KBUILD_OUTPUT) && /bin/pwd)
-+$(if $(KBUILD_OUTPUT),, \
-+ $(error output directory "$(saved-output)" does not exist))
-+
-+PHONY += $(MAKECMDGOALS)
-+
-+$(filter-out _all,$(MAKECMDGOALS)) _all:
-+ $(if $(KBUILD_VERBOSE:1=),@)$(MAKE) -C $(KBUILD_OUTPUT) \
-+ KBUILD_SRC=$(CURDIR) \
-+ KBUILD_EXTMOD="$(KBUILD_EXTMOD)" -f $(CURDIR)/Makefile $@
-+
-+# Leave processing to above invocation of make
-+skip-makefile := 1
-+endif # ifneq ($(KBUILD_OUTPUT),)
-+endif # ifeq ($(KBUILD_SRC),)
-+
-+# We process the rest of the Makefile if this is the final invocation of make
-+ifeq ($(skip-makefile),)
-+
-+# If building an external module we do not care about the all: rule
-+# but instead _all depend on modules
-+PHONY += all
-+ifeq ($(KBUILD_EXTMOD),)
-+_all: all
-+else
-+_all: modules
-+endif
++Since 'foo' is stored on a read-only branch, it cannot be removed. A
++whiteout is used to remove the name 'foo' from the unified namespace. Again,
++since branch 1 is read-only, the whiteout cannot be created there. So, we
++try on a higher priority (lower numerically) branch and create the whiteout
++there.
+
-+srctree := $(if $(KBUILD_SRC),$(KBUILD_SRC),$(CURDIR))
-+TOPDIR := $(srctree)
-+# FIXME - TOPDIR is obsolete, use srctree/objtree
-+objtree := $(CURDIR)
-+src := $(srctree)
-+obj := $(objtree)
++./b0/
++./b0/.wh.foo
++./b1/
++./b1/foo
+
-+VPATH := $(srctree)$(if $(KBUILD_EXTMOD),:$(KBUILD_EXTMOD))
++Later, when Unionfs traverses branches (due to lookup or readdir), it
++eliminate 'foo' from the namespace (as well as the whiteout itself.)
+
-+export srctree objtree VPATH TOPDIR
+
++Duplicate Elimination:
++======================
+
-+# SUBARCH tells the usermode build what the underlying arch is. That is set
-+# first, and if a usermode build is happening, the "ARCH=um" on the command
-+# line overrides the setting of ARCH below. If a native build is happening,
-+# then ARCH is assigned, getting whatever value it gets normally, and
-+# SUBARCH is subsequently ignored.
++It is possible for files on different branches to have the same name.
++Unionfs then has to select which instance of the file to show to the user.
++Given the fact that each branch has a priority associated with it, the
++simplest solution is to take the instance from the highest priority
++(numerically lowest value) and "hide" the others.
+
-+SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \
-+ -e s/arm.*/arm/ -e s/sa110/arm/ \
-+ -e s/s390x/s390/ -e s/parisc64/parisc/ \
-+ -e s/ppc.*/powerpc/ -e s/mips.*/mips/ )
+
-+# Cross compiling and selecting different set of gcc/bin-utils
-+# ---------------------------------------------------------------------------
-+#
-+# When performing cross compilation for other architectures ARCH shall be set
-+# to the target architecture. (See arch/* for the possibilities).
-+# ARCH can be set during invocation of make:
-+# make ARCH=ia64
-+# Another way is to have ARCH set in the environment.
-+# The default ARCH is the host where make is executed.
-+
-+# CROSS_COMPILE specify the prefix used for all executables used
-+# during compilation. Only gcc and related bin-utils executables
-+# are prefixed with $(CROSS_COMPILE).
-+# CROSS_COMPILE can be set on the command line
-+# make CROSS_COMPILE=ia64-linux-
-+# Alternatively CROSS_COMPILE can be set in the environment.
-+# Default value for CROSS_COMPILE is not to prefix executables
-+# Note: Some architectures assign CROSS_COMPILE in their arch/*/Makefile
-+
-+ARCH ?= $(SUBARCH)
-+CROSS_COMPILE ?=
-+
-+# Architecture as present in compile.h
-+UTS_MACHINE := $(ARCH)
-+
-+KCONFIG_CONFIG ?= .config
-+
-+# SHELL used by kbuild
-+CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
-+ else if [ -x /bin/bash ]; then echo /bin/bash; \
-+ else echo sh; fi ; fi)
-+
-+HOSTCC = gcc
-+HOSTCXX = g++
-+HOSTCFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
-+HOSTCXXFLAGS = -O2
-+
-+# Decide whether to build built-in, modular, or both.
-+# Normally, just do built-in.
-+
-+KBUILD_MODULES :=
-+KBUILD_BUILTIN := 1
-+
-+# If we have only "make modules", don't compile built-in objects.
-+# When we're building modules with modversions, we need to consider
-+# the built-in objects during the descend as well, in order to
-+# make sure the checksums are up to date before we record them.
-+
-+ifeq ($(MAKECMDGOALS),modules)
-+ KBUILD_BUILTIN := $(if $(CONFIG_MODVERSIONS),1)
-+endif
++Copyup:
++=======
+
-+# If we have "make modules", compile modules
-+# in addition to whatever we do anyway.
-+# Just "make" or "make all" shall build modules as well
++When a change is made to the contents of a file's data or meta-data, they
++have to be stored somewhere. The best way is to create a copy of the
++original file on a branch that is writable, and then redirect the write
++though to this copy. The copy must be made on a higher priority branch so
++that lookup and readdir return this newer "version" of the file rather than
++the original (see duplicate elimination).
+
-+ifneq ($(filter all _all modules,$(MAKECMDGOALS)),)
-+ KBUILD_MODULES := 1
-+endif
+
-+ifeq ($(MAKECMDGOALS),)
-+ KBUILD_MODULES := 1
-+endif
++For more information, see .
+diff -Nurb linux-2.6.22-570/Documentation/filesystems/unionfs/issues.txt linux-2.6.22-590/Documentation/filesystems/unionfs/issues.txt
+--- linux-2.6.22-570/Documentation/filesystems/unionfs/issues.txt 1969-12-31 19:00:00.000000000 -0500
++++ linux-2.6.22-590/Documentation/filesystems/unionfs/issues.txt 2008-01-29 22:12:30.000000000 -0500
+@@ -0,0 +1,39 @@
++KNOWN Unionfs 2.0 ISSUES:
++=========================
+
-+export KBUILD_MODULES KBUILD_BUILTIN
-+export KBUILD_CHECKSRC KBUILD_SRC KBUILD_EXTMOD
++1. The NFS server returns -EACCES for read-only exports, instead of -EROFS.
++ This means we can't reliably detect a read-only NFS export.
+
-+# Beautify output
-+# ---------------------------------------------------------------------------
-+#
-+# Normally, we echo the whole command before executing it. By making
-+# that echo $($(quiet)$(cmd)), we now have the possibility to set
-+# $(quiet) to choose other forms of output instead, e.g.
-+#
-+# quiet_cmd_cc_o_c = Compiling $(RELDIR)/$@
-+# cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $<
-+#
-+# If $(quiet) is empty, the whole command will be printed.
-+# If it is set to "quiet_", only the short version will be printed.
-+# If it is set to "silent_", nothing will be printed at all, since
-+# the variable $(silent_cmd_cc_o_c) doesn't exist.
-+#
-+# A simple variant is to prefix commands with $(Q) - that's useful
-+# for commands that shall be hidden in non-verbose mode.
-+#
-+# $(Q)ln $@ :<
-+#
-+# If KBUILD_VERBOSE equals 0 then the above command will be hidden.
-+# If KBUILD_VERBOSE equals 1 then the above command is displayed.
++2. Modifying a Unionfs branch directly, while the union is mounted, is
++ currently unsupported, because it could cause a cache incoherency between
++ the union layer and the lower file systems (for that reason, Unionfs
++ currently prohibits using branches which overlap with each other, even
++ partially). We have tested Unionfs under such conditions, and fixed any
++ bugs we found (Unionfs comes with an extensive regression test suite).
++ However, it may still be possible that changes made to lower branches
++ directly could cause cache incoherency which, in the worst case, may case
++ an oops.
+
-+ifeq ($(KBUILD_VERBOSE),1)
-+ quiet =
-+ Q =
-+else
-+ quiet=quiet_
-+ Q = @
-+endif
++ Unionfs 2.0 has a temporary workaround for this. You can force Unionfs
++ to increase the superblock generation number, and hence purge all cached
++ Unionfs objects, which would then be re-gotten from the lower branches.
++ This should ensure cache consistency. To increase the generation number,
++ executed the command:
+
-+# If the user is running make -s (silent mode), suppress echoing of
-+# commands
++ mount -t unionfs -o remount,incgen none MOUNTPOINT
+
-+ifneq ($(findstring s,$(MAKEFLAGS)),)
-+ quiet=silent_
-+endif
++ Note that the older way of incrementing the generation number using an
++ ioctl, is no longer supported in Unionfs 2.0. Ioctls in general are not
++ encouraged. Plus, an ioctl is per-file concept, whereas the generation
++ number is a per-file-system concept. Worse, such an ioctl requires an
++ open file, which then has to be invalidated by the very nature of the
++ generation number increase (read: the old generation increase ioctl was
++ pretty racy).
+
-+export quiet Q KBUILD_VERBOSE
-+
-+
-+# Look for make include files relative to root of kernel src
-+MAKEFLAGS += --include-dir=$(srctree)
-+
-+# We need some generic definitions.
-+include $(srctree)/scripts/Kbuild.include
-+
-+# Make variables (CC, etc...)
-+
-+AS = $(CROSS_COMPILE)as
-+LD = $(CROSS_COMPILE)ld
-+CC = $(CROSS_COMPILE)gcc
-+CPP = $(CC) -E
-+AR = $(CROSS_COMPILE)ar
-+NM = $(CROSS_COMPILE)nm
-+STRIP = $(CROSS_COMPILE)strip
-+OBJCOPY = $(CROSS_COMPILE)objcopy
-+OBJDUMP = $(CROSS_COMPILE)objdump
-+AWK = awk
-+GENKSYMS = scripts/genksyms/genksyms
-+DEPMOD = /sbin/depmod
-+KALLSYMS = scripts/kallsyms
-+PERL = perl
-+CHECK = sparse
-+
-+CHECKFLAGS := -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__ -Wbitwise $(CF)
-+MODFLAGS = -DMODULE
-+CFLAGS_MODULE = $(MODFLAGS)
-+AFLAGS_MODULE = $(MODFLAGS)
-+LDFLAGS_MODULE = -r
-+CFLAGS_KERNEL =
-+AFLAGS_KERNEL =
-+
-+
-+# Use LINUXINCLUDE when you must reference the include/ directory.
-+# Needed to be compatible with the O= option
-+LINUXINCLUDE := -Iinclude \
-+ $(if $(KBUILD_SRC),-Iinclude2 -I$(srctree)/include) \
-+ -include include/linux/autoconf.h
-+
-+CPPFLAGS := -D__KERNEL__ $(LINUXINCLUDE)
-+
-+CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
-+ -fno-strict-aliasing -fno-common
-+AFLAGS := -D__ASSEMBLY__
-+
-+# Read KERNELRELEASE from include/config/kernel.release (if it exists)
-+KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null)
-+KERNELVERSION = $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
-+
-+export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION
-+export ARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC
-+export CPP AR NM STRIP OBJCOPY OBJDUMP MAKE AWK GENKSYMS PERL UTS_MACHINE
-+export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
-+
-+export CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
-+export CFLAGS CFLAGS_KERNEL CFLAGS_MODULE
-+export AFLAGS AFLAGS_KERNEL AFLAGS_MODULE
-+
-+# When compiling out-of-tree modules, put MODVERDIR in the module
-+# tree rather than in the kernel tree. The kernel tree might
-+# even be read-only.
-+export MODVERDIR := $(if $(KBUILD_EXTMOD),$(firstword $(KBUILD_EXTMOD))/).tmp_versions
-+
-+# Files to ignore in find ... statements
-+
-+RCS_FIND_IGNORE := \( -name SCCS -o -name BitKeeper -o -name .svn -o -name CVS -o -name .pc -o -name .hg -o -name .git \) -prune -o
-+export RCS_TAR_IGNORE := --exclude SCCS --exclude BitKeeper --exclude .svn --exclude CVS --exclude .pc --exclude .hg --exclude .git
-+
-+# ===========================================================================
-+# Rules shared between *config targets and build targets
-+
-+# Basic helpers built in scripts/
-+PHONY += scripts_basic
-+scripts_basic:
-+ $(Q)$(MAKE) $(build)=scripts/basic
-+
-+# To avoid any implicit rule to kick in, define an empty command.
-+scripts/basic/%: scripts_basic ;
-+
-+PHONY += outputmakefile
-+# outputmakefile generates a Makefile in the output directory, if using a
-+# separate output directory. This allows convenient use of make in the
-+# output directory.
-+outputmakefile:
-+ifneq ($(KBUILD_SRC),)
-+ $(Q)$(CONFIG_SHELL) $(srctree)/scripts/mkmakefile \
-+ $(srctree) $(objtree) $(VERSION) $(PATCHLEVEL)
-+endif
++3. Unionfs should not use lookup_one_len() on the underlying f/s as it
++ confuses NFS. Currently, unionfs_lookup() passes lookup intents to the
++ lower file-system, this eliminates part of the problem. The remaining
++ calls to lookup_one_len may need to be changed to pass an intent.
+
-+# To make sure we do not include .config for any of the *config targets
-+# catch them early, and hand them over to scripts/kconfig/Makefile
-+# It is allowed to specify more targets when calling make, including
-+# mixing *config targets and build targets.
-+# For example 'make oldconfig all'.
-+# Detect when mixed targets is specified, and make a second invocation
-+# of make so .config is not included in this case either (for *config).
-+
-+no-dot-config-targets := clean mrproper distclean \
-+ cscope TAGS tags help %docs check% \
-+ include/linux/version.h headers_% \
-+ kernelrelease kernelversion
-+
-+config-targets := 0
-+mixed-targets := 0
-+dot-config := 1
-+
-+ifneq ($(filter $(no-dot-config-targets), $(MAKECMDGOALS)),)
-+ ifeq ($(filter-out $(no-dot-config-targets), $(MAKECMDGOALS)),)
-+ dot-config := 0
-+ endif
-+endif
+
-+ifeq ($(KBUILD_EXTMOD),)
-+ ifneq ($(filter config %config,$(MAKECMDGOALS)),)
-+ config-targets := 1
-+ ifneq ($(filter-out config %config,$(MAKECMDGOALS)),)
-+ mixed-targets := 1
-+ endif
-+ endif
-+endif
++For more information, see .
+diff -Nurb linux-2.6.22-570/Documentation/filesystems/unionfs/rename.txt linux-2.6.22-590/Documentation/filesystems/unionfs/rename.txt
+--- linux-2.6.22-570/Documentation/filesystems/unionfs/rename.txt 1969-12-31 19:00:00.000000000 -0500
++++ linux-2.6.22-590/Documentation/filesystems/unionfs/rename.txt 2008-01-29 22:12:30.000000000 -0500
+@@ -0,0 +1,31 @@
++Rename is a complex beast. The following table shows which rename(2) operations
++should succeed and which should fail.
+
-+ifeq ($(mixed-targets),1)
-+# ===========================================================================
-+# We're called with mixed targets (*config and build targets).
-+# Handle them one by one.
++o: success
++E: error (either unionfs or vfs)
++X: EXDEV
+
-+%:: FORCE
-+ $(Q)$(MAKE) -C $(srctree) KBUILD_SRC= $@
++none = file does not exist
++file = file is a file
++dir = file is a empty directory
++child= file is a non-empty directory
++wh = file is a directory containing only whiteouts; this makes it logically
++ empty
+
-+else
-+ifeq ($(config-targets),1)
-+# ===========================================================================
-+# *config targets only - make sure prerequisites are updated, and descend
-+# in scripts/kconfig to make the *config target
++ none file dir child wh
++file o o E E E
++dir o E o E o
++child X E X E X
++wh o E o E o
+
-+# Read arch specific Makefile to set KBUILD_DEFCONFIG as needed.
-+# KBUILD_DEFCONFIG may point out an alternative default configuration
-+# used for 'make defconfig'
-+include $(srctree)/arch/$(ARCH)/Makefile
-+export KBUILD_DEFCONFIG
+
-+config %config: scripts_basic outputmakefile FORCE
-+ $(Q)mkdir -p include/linux include/config
-+ $(Q)$(MAKE) $(build)=scripts/kconfig $@
++Renaming directories:
++=====================
+
-+else
-+# ===========================================================================
-+# Build targets only - this includes vmlinux, arch specific targets, clean
-+# targets and others. In general all targets except *config targets.
-+
-+ifeq ($(KBUILD_EXTMOD),)
-+# Additional helpers built in scripts/
-+# Carefully list dependencies so we do not try to build scripts twice
-+# in parallel
-+PHONY += scripts
-+scripts: scripts_basic include/config/auto.conf
-+ $(Q)$(MAKE) $(build)=$(@)
-+
-+# Objects we will link into vmlinux / subdirs we need to visit
-+init-y := init/
-+drivers-y := drivers/ sound/
-+net-y := net/
-+libs-y := lib/
-+core-y := usr/
-+endif # KBUILD_EXTMOD
-+
-+ifeq ($(dot-config),1)
-+# Read in config
-+-include include/config/auto.conf
-+
-+ifeq ($(KBUILD_EXTMOD),)
-+# Read in dependencies to all Kconfig* files, make sure to run
-+# oldconfig if changes are detected.
-+-include include/config/auto.conf.cmd
-+
-+# To avoid any implicit rule to kick in, define an empty command
-+$(KCONFIG_CONFIG) include/config/auto.conf.cmd: ;
-+
-+# If .config is newer than include/config/auto.conf, someone tinkered
-+# with it and forgot to run make oldconfig.
-+# if auto.conf.cmd is missing then we are probably in a cleaned tree so
-+# we execute the config step to be sure to catch updated Kconfig files
-+include/config/auto.conf: $(KCONFIG_CONFIG) include/config/auto.conf.cmd
-+ $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
-+else
-+# external modules needs include/linux/autoconf.h and include/config/auto.conf
-+# but do not care if they are up-to-date. Use auto.conf to trigger the test
-+PHONY += include/config/auto.conf
++Whenever a empty (either physically or logically) directory is being renamed,
++the following sequence of events should take place:
+
-+include/config/auto.conf:
-+ $(Q)test -e include/linux/autoconf.h -a -e $@ || ( \
-+ echo; \
-+ echo " ERROR: Kernel configuration is invalid."; \
-+ echo " include/linux/autoconf.h or $@ are missing."; \
-+ echo " Run 'make oldconfig && make prepare' on kernel src to fix it."; \
-+ echo; \
-+ /bin/false)
++1) Remove whiteouts from both source and destination directory
++2) Rename source to destination
++3) Make destination opaque to prevent anything under it from showing up
+
-+endif # KBUILD_EXTMOD
+diff -Nurb linux-2.6.22-570/Documentation/filesystems/unionfs/usage.txt linux-2.6.22-590/Documentation/filesystems/unionfs/usage.txt
+--- linux-2.6.22-570/Documentation/filesystems/unionfs/usage.txt 1969-12-31 19:00:00.000000000 -0500
++++ linux-2.6.22-590/Documentation/filesystems/unionfs/usage.txt 2008-01-29 22:12:30.000000000 -0500
+@@ -0,0 +1,90 @@
++Unionfs is a stackable unification file system, which can appear to merge
++the contents of several directories (branches), while keeping their physical
++content separate. Unionfs is useful for unified source tree management,
++merged contents of split CD-ROM, merged separate software package
++directories, data grids, and more. Unionfs allows any mix of read-only and
++read-write branches, as well as insertion and deletion of branches anywhere
++in the fan-out. To maintain Unix semantics, Unionfs handles elimination of
++duplicates, partial-error conditions, and more.
+
-+else
-+# Dummy target needed, because used as prerequisite
-+include/config/auto.conf: ;
-+endif # $(dot-config)
-+
-+# The all: target is the default when no target is given on the
-+# command line.
-+# This allow a user to issue only 'make' to build a kernel including modules
-+# Defaults vmlinux but it is usually overridden in the arch makefile
-+all: vmlinux
-+
-+ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
-+CFLAGS += -Os
-+else
-+CFLAGS += -O2
-+endif
++# mount -t unionfs -o branch-option[,union-options[,...]] none MOUNTPOINT
+
-+include $(srctree)/arch/$(ARCH)/Makefile
++The available branch-option for the mount command is:
+
-+ifdef CONFIG_FRAME_POINTER
-+CFLAGS += -fno-omit-frame-pointer $(call cc-option,-fno-optimize-sibling-calls,)
-+else
-+CFLAGS += -fomit-frame-pointer
-+endif
++ dirs=branch[=ro|=rw][:...]
+
-+ifdef CONFIG_DEBUG_INFO
-+CFLAGS += -g
-+endif
++specifies a separated list of which directories compose the union.
++Directories that come earlier in the list have a higher precedence than
++those which come later. Additionally, read-only or read-write permissions of
++the branch can be specified by appending =ro or =rw (default) to each
++directory.
+
-+# Force gcc to behave correct even for buggy distributions
-+CFLAGS += $(call cc-option, -fno-stack-protector)
++Syntax:
+
-+# arch Makefile may override CC so keep this after arch Makefile is included
-+NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
-+CHECKFLAGS += $(NOSTDINC_FLAGS)
++ dirs=/branch1[=ro|=rw]:/branch2[=ro|=rw]:...:/branchN[=ro|=rw]
+
-+# warn about C99 declaration after statement
-+CFLAGS += $(call cc-option,-Wdeclaration-after-statement,)
++Example:
+
-+# disable pointer signed / unsigned warnings in gcc 4.0
-+CFLAGS += $(call cc-option,-Wno-pointer-sign,)
++ dirs=/writable_branch=rw:/read-only_branch=ro
+
-+# Default kernel image to build when no specific target is given.
-+# KBUILD_IMAGE may be overruled on the command line or
-+# set in the environment
-+# Also any assignments in arch/$(ARCH)/Makefile take precedence over
-+# this default value
-+export KBUILD_IMAGE ?= vmlinux
+
-+#
-+# INSTALL_PATH specifies where to place the updated kernel and system map
-+# images. Default is /boot, but you can set it to other values
-+export INSTALL_PATH ?= /boot
++DYNAMIC BRANCH MANAGEMENT AND REMOUNTS
++======================================
+
-+#
-+# INSTALL_MOD_PATH specifies a prefix to MODLIB for module directory
-+# relocations required by build roots. This is not defined in the
-+# makefile but the argument can be passed to make if needed.
-+#
++You can remount a union and change its overall mode, or reconfigure the
++branches, as follows.
+
-+MODLIB = $(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE)
-+export MODLIB
++To downgrade a union from read-write to read-only:
+
-+#
-+# INSTALL_MOD_STRIP, if defined, will cause modules to be
-+# stripped after they are installed. If INSTALL_MOD_STRIP is '1', then
-+# the default option --strip-debug will be used. Otherwise,
-+# INSTALL_MOD_STRIP will used as the options to the strip command.
-+
-+ifdef INSTALL_MOD_STRIP
-+ifeq ($(INSTALL_MOD_STRIP),1)
-+mod_strip_cmd = $(STRIP) --strip-debug
-+else
-+mod_strip_cmd = $(STRIP) $(INSTALL_MOD_STRIP)
-+endif # INSTALL_MOD_STRIP=1
-+else
-+mod_strip_cmd = true
-+endif # INSTALL_MOD_STRIP
-+export mod_strip_cmd
-+
-+
-+ifeq ($(KBUILD_EXTMOD),)
-+core-y += kernel/ mm/ fs/ ipc/ security/ crypto/ block/
-+
-+vmlinux-dirs := $(patsubst %/,%,$(filter %/, $(init-y) $(init-m) \
-+ $(core-y) $(core-m) $(drivers-y) $(drivers-m) \
-+ $(net-y) $(net-m) $(libs-y) $(libs-m)))
-+
-+vmlinux-alldirs := $(sort $(vmlinux-dirs) $(patsubst %/,%,$(filter %/, \
-+ $(init-n) $(init-) \
-+ $(core-n) $(core-) $(drivers-n) $(drivers-) \
-+ $(net-n) $(net-) $(libs-n) $(libs-))))
-+
-+init-y := $(patsubst %/, %/built-in.o, $(init-y))
-+core-y := $(patsubst %/, %/built-in.o, $(core-y))
-+drivers-y := $(patsubst %/, %/built-in.o, $(drivers-y))
-+net-y := $(patsubst %/, %/built-in.o, $(net-y))
-+libs-y1 := $(patsubst %/, %/lib.a, $(libs-y))
-+libs-y2 := $(patsubst %/, %/built-in.o, $(libs-y))
-+libs-y := $(libs-y1) $(libs-y2)
-+
-+# Build vmlinux
-+# ---------------------------------------------------------------------------
-+# vmlinux is built from the objects selected by $(vmlinux-init) and
-+# $(vmlinux-main). Most are built-in.o files from top-level directories
-+# in the kernel tree, others are specified in arch/$(ARCH)/Makefile.
-+# Ordering when linking is important, and $(vmlinux-init) must be first.
-+#
-+# vmlinux
-+# ^
-+# |
-+# +-< $(vmlinux-init)
-+# | +--< init/version.o + more
-+# |
-+# +--< $(vmlinux-main)
-+# | +--< driver/built-in.o mm/built-in.o + more
-+# |
-+# +-< kallsyms.o (see description in CONFIG_KALLSYMS section)
-+#
-+# vmlinux version (uname -v) cannot be updated during normal
-+# descending-into-subdirs phase since we do not yet know if we need to
-+# update vmlinux.
-+# Therefore this step is delayed until just before final link of vmlinux -
-+# except in the kallsyms case where it is done just before adding the
-+# symbols to the kernel.
-+#
-+# System.map is generated to document addresses of all kernel symbols
-+
-+vmlinux-init := $(head-y) $(init-y)
-+vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y)
-+vmlinux-all := $(vmlinux-init) $(vmlinux-main)
-+vmlinux-lds := arch/$(ARCH)/kernel/vmlinux.lds
-+export KBUILD_VMLINUX_OBJS := $(vmlinux-all)
-+
-+# Rule to link vmlinux - also used during CONFIG_KALLSYMS
-+# May be overridden by arch/$(ARCH)/Makefile
-+quiet_cmd_vmlinux__ ?= LD $@
-+ cmd_vmlinux__ ?= $(LD) $(LDFLAGS) $(LDFLAGS_vmlinux) -o $@ \
-+ -T $(vmlinux-lds) $(vmlinux-init) \
-+ --start-group $(vmlinux-main) --end-group \
-+ $(filter-out $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) FORCE ,$^)
-+
-+# Generate new vmlinux version
-+quiet_cmd_vmlinux_version = GEN .version
-+ cmd_vmlinux_version = set -e; \
-+ if [ ! -r .version ]; then \
-+ rm -f .version; \
-+ echo 1 >.version; \
-+ else \
-+ mv .version .old_version; \
-+ expr 0$$(cat .old_version) + 1 >.version; \
-+ fi; \
-+ $(MAKE) $(build)=init
-+
-+# Generate System.map
-+quiet_cmd_sysmap = SYSMAP
-+ cmd_sysmap = $(CONFIG_SHELL) $(srctree)/scripts/mksysmap
-+
-+# Link of vmlinux
-+# If CONFIG_KALLSYMS is set .version is already updated
-+# Generate System.map and verify that the content is consistent
-+# Use + in front of the vmlinux_version rule to silent warning with make -j2
-+# First command is ':' to allow us to use + in front of the rule
-+define rule_vmlinux__
-+ :
-+ $(if $(CONFIG_KALLSYMS),,+$(call cmd,vmlinux_version))
-+
-+ $(call cmd,vmlinux__)
-+ $(Q)echo 'cmd_$@ := $(cmd_vmlinux__)' > $(@D)/.$(@F).cmd
-+
-+ $(Q)$(if $($(quiet)cmd_sysmap), \
-+ echo ' $($(quiet)cmd_sysmap) System.map' &&) \
-+ $(cmd_sysmap) $@ System.map; \
-+ if [ $$? -ne 0 ]; then \
-+ rm -f $@; \
-+ /bin/false; \
-+ fi;
-+ $(verify_kallsyms)
-+endef
-+
-+
-+ifdef CONFIG_KALLSYMS
-+# Generate section listing all symbols and add it into vmlinux $(kallsyms.o)
-+# It's a three stage process:
-+# o .tmp_vmlinux1 has all symbols and sections, but __kallsyms is
-+# empty
-+# Running kallsyms on that gives us .tmp_kallsyms1.o with
-+# the right size - vmlinux version (uname -v) is updated during this step
-+# o .tmp_vmlinux2 now has a __kallsyms section of the right size,
-+# but due to the added section, some addresses have shifted.
-+# From here, we generate a correct .tmp_kallsyms2.o
-+# o The correct .tmp_kallsyms2.o is linked into the final vmlinux.
-+# o Verify that the System.map from vmlinux matches the map from
-+# .tmp_vmlinux2, just in case we did not generate kallsyms correctly.
-+# o If CONFIG_KALLSYMS_EXTRA_PASS is set, do an extra pass using
-+# .tmp_vmlinux3 and .tmp_kallsyms3.o. This is only meant as a
-+# temporary bypass to allow the kernel to be built while the
-+# maintainers work out what went wrong with kallsyms.
-+
-+ifdef CONFIG_KALLSYMS_EXTRA_PASS
-+last_kallsyms := 3
-+else
-+last_kallsyms := 2
-+endif
++# mount -t unionfs -o remount,ro none MOUNTPOINT
+
-+kallsyms.o := .tmp_kallsyms$(last_kallsyms).o
++To upgrade a union from read-only to read-write:
+
-+define verify_kallsyms
-+ $(Q)$(if $($(quiet)cmd_sysmap), \
-+ echo ' $($(quiet)cmd_sysmap) .tmp_System.map' &&) \
-+ $(cmd_sysmap) .tmp_vmlinux$(last_kallsyms) .tmp_System.map
-+ $(Q)cmp -s System.map .tmp_System.map || \
-+ (echo Inconsistent kallsyms data; \
-+ echo Try setting CONFIG_KALLSYMS_EXTRA_PASS; \
-+ rm .tmp_kallsyms* ; /bin/false )
-+endef
++# mount -t unionfs -o remount,rw none MOUNTPOINT
+
-+# Update vmlinux version before link
-+# Use + in front of this rule to silent warning about make -j1
-+# First command is ':' to allow us to use + in front of this rule
-+cmd_ksym_ld = $(cmd_vmlinux__)
-+define rule_ksym_ld
-+ :
-+ +$(call cmd,vmlinux_version)
-+ $(call cmd,vmlinux__)
-+ $(Q)echo 'cmd_$@ := $(cmd_vmlinux__)' > $(@D)/.$(@F).cmd
-+endef
++To delete a branch /foo, regardless where it is in the current union:
+
-+# Generate .S file with all kernel symbols
-+quiet_cmd_kallsyms = KSYM $@
-+ cmd_kallsyms = $(NM) -n $< | $(KALLSYMS) \
-+ $(if $(CONFIG_KALLSYMS_ALL),--all-symbols) > $@
++# mount -t unionfs -o del=/foo none MOUNTPOINT
+
-+.tmp_kallsyms1.o .tmp_kallsyms2.o .tmp_kallsyms3.o: %.o: %.S scripts FORCE
-+ $(call if_changed_dep,as_o_S)
++To insert (add) a branch /foo before /bar:
+
-+.tmp_kallsyms%.S: .tmp_vmlinux% $(KALLSYMS)
-+ $(call cmd,kallsyms)
++# mount -t unionfs -o remount,add=/bar:/foo none MOUNTPOINT
+
-+# .tmp_vmlinux1 must be complete except kallsyms, so update vmlinux version
-+.tmp_vmlinux1: $(vmlinux-lds) $(vmlinux-all) FORCE
-+ $(call if_changed_rule,ksym_ld)
++To insert (add) a branch /foo (with the "rw" mode flag) before /bar:
+
-+.tmp_vmlinux2: $(vmlinux-lds) $(vmlinux-all) .tmp_kallsyms1.o FORCE
-+ $(call if_changed,vmlinux__)
++# mount -t unionfs -o remount,add=/bar:/foo=rw none MOUNTPOINT
+
-+.tmp_vmlinux3: $(vmlinux-lds) $(vmlinux-all) .tmp_kallsyms2.o FORCE
-+ $(call if_changed,vmlinux__)
++To insert (add) a branch /foo (in "rw" mode) at the very beginning (i.e., a
++new highest-priority branch), you can use the above syntax, or use a short
++hand version as follows:
+
-+# Needs to visit scripts/ before $(KALLSYMS) can be used.
-+$(KALLSYMS): scripts ;
++# mount -t unionfs -o remount,add=/foo none MOUNTPOINT
+
-+# Generate some data for debugging strange kallsyms problems
-+debug_kallsyms: .tmp_map$(last_kallsyms)
++To append a branch to the very end (new lowest-priority branch):
+
-+.tmp_map%: .tmp_vmlinux% FORCE
-+ ($(OBJDUMP) -h $< | $(AWK) '/^ +[0-9]/{print $$4 " 0 " $$2}'; $(NM) $<) | sort > $@
++# mount -t unionfs -o remount,add=:/foo none MOUNTPOINT
+
-+.tmp_map3: .tmp_map2
++To append a branch to the very end (new lowest-priority branch), in
++read-only mode:
+
-+.tmp_map2: .tmp_map1
++# mount -t unionfs -o remount,add=:/foo:ro none MOUNTPOINT
+
-+endif # ifdef CONFIG_KALLSYMS
++Finally, to change the mode of one existing branch, say /foo, from read-only
++to read-write, and change /bar from read-write to read-only:
+
-+# vmlinux image - including updated kernel symbols
-+vmlinux: $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) $(kallsyms.o) FORCE
-+ifdef CONFIG_HEADERS_CHECK
-+ $(Q)$(MAKE) -f $(srctree)/Makefile headers_check
-+endif
-+ $(call if_changed_rule,vmlinux__)
-+ $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost $@
-+ $(Q)rm -f .old_version
++# mount -t unionfs -o remount,mode=/foo=rw,mode=/bar=ro none MOUNTPOINT
+
-+# The actual objects are generated when descending,
-+# make sure no implicit rule kicks in
-+$(sort $(vmlinux-init) $(vmlinux-main)) $(vmlinux-lds): $(vmlinux-dirs) ;
+
-+# Handle descending into subdirectories listed in $(vmlinux-dirs)
-+# Preset locale variables to speed up the build process. Limit locale
-+# tweaks to this spot to avoid wrong language settings when running
-+# make menuconfig etc.
-+# Error messages still appears in the original language
++CACHE CONSISTENCY
++=================
+
-+PHONY += $(vmlinux-dirs)
-+$(vmlinux-dirs): prepare scripts
-+ $(Q)$(MAKE) $(build)=$@
++If you modify any file on any of the lower branches directly, while there is
++a Unionfs 2.0 mounted above any of those branches, you should tell Unionfs
++to purge its caches and re-get the objects. To do that, you have to
++increment the generation number of the superblock using the following
++command:
+
-+# Build the kernel release string
-+#
-+# The KERNELRELEASE value built here is stored in the file
-+# include/config/kernel.release, and is used when executing several
-+# make targets, such as "make install" or "make modules_install."
-+#
-+# The eventual kernel release string consists of the following fields,
-+# shown in a hierarchical format to show how smaller parts are concatenated
-+# to form the larger and final value, with values coming from places like
-+# the Makefile, kernel config options, make command line options and/or
-+# SCM tag information.
-+#
-+# $(KERNELVERSION)
-+# $(VERSION) eg, 2
-+# $(PATCHLEVEL) eg, 6
-+# $(SUBLEVEL) eg, 18
-+# $(EXTRAVERSION) eg, -rc6
-+# $(localver-full)
-+# $(localver)
-+# localversion* (files without backups, containing '~')
-+# $(CONFIG_LOCALVERSION) (from kernel config setting)
-+# $(localver-auto) (only if CONFIG_LOCALVERSION_AUTO is set)
-+# ./scripts/setlocalversion (SCM tag, if one exists)
-+# $(LOCALVERSION) (from make command line if provided)
-+#
-+# Note how the final $(localver-auto) string is included *only* if the
-+# kernel config option CONFIG_LOCALVERSION_AUTO is selected. Also, at the
-+# moment, only git is supported but other SCMs can edit the script
-+# scripts/setlocalversion and add the appropriate checks as needed.
++# mount -t unionfs -o remount,incgen none MOUNTPOINT
+
-+pattern = ".*/localversion[^~]*"
-+string = $(shell cat /dev/null \
-+ `find $(objtree) $(srctree) -maxdepth 1 -regex $(pattern) | sort -u`)
+
-+localver = $(subst $(space),, $(string) \
-+ $(patsubst "%",%,$(CONFIG_LOCALVERSION)))
++For more information, see .
+diff -Nurb linux-2.6.22-570/Documentation/firmware_class/firmware_sample_firmware_class.c linux-2.6.22-590/Documentation/firmware_class/firmware_sample_firmware_class.c
+--- linux-2.6.22-570/Documentation/firmware_class/firmware_sample_firmware_class.c 2007-07-08 19:32:17.000000000 -0400
++++ linux-2.6.22-590/Documentation/firmware_class/firmware_sample_firmware_class.c 2008-01-29 22:12:30.000000000 -0500
+@@ -78,6 +78,7 @@
+ firmware_loading_show, firmware_loading_store);
+
+ static ssize_t firmware_data_read(struct kobject *kobj,
++ struct bin_attribute *bin_attr,
+ char *buffer, loff_t offset, size_t count)
+ {
+ struct class_device *class_dev = to_class_dev(kobj);
+@@ -88,6 +89,7 @@
+ return count;
+ }
+ static ssize_t firmware_data_write(struct kobject *kobj,
++ struct bin_attribute *bin_attr,
+ char *buffer, loff_t offset, size_t count)
+ {
+ struct class_device *class_dev = to_class_dev(kobj);
+diff -Nurb linux-2.6.22-570/Documentation/power/freezing-of-tasks.txt linux-2.6.22-590/Documentation/power/freezing-of-tasks.txt
+--- linux-2.6.22-570/Documentation/power/freezing-of-tasks.txt 1969-12-31 19:00:00.000000000 -0500
++++ linux-2.6.22-590/Documentation/power/freezing-of-tasks.txt 2008-01-29 22:12:30.000000000 -0500
+@@ -0,0 +1,160 @@
++Freezing of tasks
++ (C) 2007 Rafael J. Wysocki , GPL
++
++I. What is the freezing of tasks?
++
++The freezing of tasks is a mechanism by which user space processes and some
++kernel threads are controlled during hibernation or system-wide suspend (on some
++architectures).
++
++II. How does it work?
++
++There are four per-task flags used for that, PF_NOFREEZE, PF_FROZEN, TIF_FREEZE
++and PF_FREEZER_SKIP (the last one is auxiliary). The tasks that have
++PF_NOFREEZE unset (all user space processes and some kernel threads) are
++regarded as 'freezable' and treated in a special way before the system enters a
++suspend state as well as before a hibernation image is created (in what follows
++we only consider hibernation, but the description also applies to suspend).
++
++Namely, as the first step of the hibernation procedure the function
++freeze_processes() (defined in kernel/power/process.c) is called. It executes
++try_to_freeze_tasks() that sets TIF_FREEZE for all of the freezable tasks and
++sends a fake signal to each of them. A task that receives such a signal and has
++TIF_FREEZE set, should react to it by calling the refrigerator() function
++(defined in kernel/power/process.c), which sets the task's PF_FROZEN flag,
++changes its state to TASK_UNINTERRUPTIBLE and makes it loop until PF_FROZEN is
++cleared for it. Then, we say that the task is 'frozen' and therefore the set of
++functions handling this mechanism is called 'the freezer' (these functions are
++defined in kernel/power/process.c and include/linux/freezer.h). User space
++processes are generally frozen before kernel threads.
++
++It is not recommended to call refrigerator() directly. Instead, it is
++recommended to use the try_to_freeze() function (defined in
++include/linux/freezer.h), that checks the task's TIF_FREEZE flag and makes the
++task enter refrigerator() if the flag is set.
++
++For user space processes try_to_freeze() is called automatically from the
++signal-handling code, but the freezable kernel threads need to call it
++explicitly in suitable places. The code to do this may look like the following:
+
-+# If CONFIG_LOCALVERSION_AUTO is set scripts/setlocalversion is called
-+# and if the SCM is know a tag from the SCM is appended.
-+# The appended tag is determined by the SCM used.
-+#
-+# Currently, only git is supported.
-+# Other SCMs can edit scripts/setlocalversion and add the appropriate
-+# checks as needed.
-+ifdef CONFIG_LOCALVERSION_AUTO
-+ _localver-auto = $(shell $(CONFIG_SHELL) \
-+ $(srctree)/scripts/setlocalversion $(srctree))
-+ localver-auto = $(LOCALVERSION)$(_localver-auto)
-+endif
++ do {
++ hub_events();
++ wait_event_interruptible(khubd_wait,
++ !list_empty(&hub_event_list));
++ try_to_freeze();
++ } while (!signal_pending(current));
++
++(from drivers/usb/core/hub.c::hub_thread()).
++
++If a freezable kernel thread fails to call try_to_freeze() after the freezer has
++set TIF_FREEZE for it, the freezing of tasks will fail and the entire
++hibernation operation will be cancelled. For this reason, freezable kernel
++threads must call try_to_freeze() somewhere.
++
++After the system memory state has been restored from a hibernation image and
++devices have been reinitialized, the function thaw_processes() is called in
++order to clear the PF_FROZEN flag for each frozen task. Then, the tasks that
++have been frozen leave refrigerator() and continue running.
++
++III. Which kernel threads are freezable?
++
++Kernel threads are not freezable by default. However, a kernel thread may clear
++PF_NOFREEZE for itself by calling set_freezable() (the resetting of PF_NOFREEZE
++directly is strongly discouraged). From this point it is regarded as freezable
++and must call try_to_freeze() in a suitable place.
++
++IV. Why do we do that?
++
++Generally speaking, there is a couple of reasons to use the freezing of tasks:
++
++1. The principal reason is to prevent filesystems from being damaged after
++hibernation. At the moment we have no simple means of checkpointing
++filesystems, so if there are any modifications made to filesystem data and/or
++metadata on disks, we cannot bring them back to the state from before the
++modifications. At the same time each hibernation image contains some
++filesystem-related information that must be consistent with the state of the
++on-disk data and metadata after the system memory state has been restored from
++the image (otherwise the filesystems will be damaged in a nasty way, usually
++making them almost impossible to repair). We therefore freeze tasks that might
++cause the on-disk filesystems' data and metadata to be modified after the
++hibernation image has been created and before the system is finally powered off.
++The majority of these are user space processes, but if any of the kernel threads
++may cause something like this to happen, they have to be freezable.
++
++2. The second reason is to prevent user space processes and some kernel threads
++from interfering with the suspending and resuming of devices. A user space
++process running on a second CPU while we are suspending devices may, for
++example, be troublesome and without the freezing of tasks we would need some
++safeguards against race conditions that might occur in such a case.
++
++Although Linus Torvalds doesn't like the freezing of tasks, he said this in one
++of the discussions on LKML (http://lkml.org/lkml/2007/4/27/608):
++
++"RJW:> Why we freeze tasks at all or why we freeze kernel threads?
++
++Linus: In many ways, 'at all'.
++
++I _do_ realize the IO request queue issues, and that we cannot actually do
++s2ram with some devices in the middle of a DMA. So we want to be able to
++avoid *that*, there's no question about that. And I suspect that stopping
++user threads and then waiting for a sync is practically one of the easier
++ways to do so.
++
++So in practice, the 'at all' may become a 'why freeze kernel threads?' and
++freezing user threads I don't find really objectionable."
++
++Still, there are kernel threads that may want to be freezable. For example, if
++a kernel that belongs to a device driver accesses the device directly, it in
++principle needs to know when the device is suspended, so that it doesn't try to
++access it at that time. However, if the kernel thread is freezable, it will be
++frozen before the driver's .suspend() callback is executed and it will be
++thawed after the driver's .resume() callback has run, so it won't be accessing
++the device while it's suspended.
++
++3. Another reason for freezing tasks is to prevent user space processes from
++realizing that hibernation (or suspend) operation takes place. Ideally, user
++space processes should not notice that such a system-wide operation has occurred
++and should continue running without any problems after the restore (or resume
++from suspend). Unfortunately, in the most general case this is quite difficult
++to achieve without the freezing of tasks. Consider, for example, a process
++that depends on all CPUs being online while it's running. Since we need to
++disable nonboot CPUs during the hibernation, if this process is not frozen, it
++may notice that the number of CPUs has changed and may start to work incorrectly
++because of that.
++
++V. Are there any problems related to the freezing of tasks?
++
++Yes, there are.
++
++First of all, the freezing of kernel threads may be tricky if they depend one
++on another. For example, if kernel thread A waits for a completion (in the
++TASK_UNINTERRUPTIBLE state) that needs to be done by freezable kernel thread B
++and B is frozen in the meantime, then A will be blocked until B is thawed, which
++may be undesirable. That's why kernel threads are not freezable by default.
++
++Second, there are the following two problems related to the freezing of user
++space processes:
++1. Putting processes into an uninterruptible sleep distorts the load average.
++2. Now that we have FUSE, plus the framework for doing device drivers in
++userspace, it gets even more complicated because some userspace processes are
++now doing the sorts of things that kernel threads do
++(https://lists.linux-foundation.org/pipermail/linux-pm/2007-May/012309.html).
++
++The problem 1. seems to be fixable, although it hasn't been fixed so far. The
++other one is more serious, but it seems that we can work around it by using
++hibernation (and suspend) notifiers (in that case, though, we won't be able to
++avoid the realization by the user space processes that the hibernation is taking
++place).
++
++There are also problems that the freezing of tasks tends to expose, although
++they are not directly related to it. For example, if request_firmware() is
++called from a device driver's .resume() routine, it will timeout and eventually
++fail, because the user land process that should respond to the request is frozen
++at this point. So, seemingly, the failure is due to the freezing of tasks.
++Suppose, however, that the firmware file is located on a filesystem accessible
++only through another device that hasn't been resumed yet. In that case,
++request_firmware() will fail regardless of whether or not the freezing of tasks
++is used. Consequently, the problem is not really related to the freezing of
++tasks, since it generally exists anyway. [The solution to this particular
++problem is to keep the firmware in memory after it's loaded for the first time
++and upload if from memory to the device whenever necessary.]
+diff -Nurb linux-2.6.22-570/Documentation/power/kernel_threads.txt linux-2.6.22-590/Documentation/power/kernel_threads.txt
+--- linux-2.6.22-570/Documentation/power/kernel_threads.txt 2007-07-08 19:32:17.000000000 -0400
++++ linux-2.6.22-590/Documentation/power/kernel_threads.txt 1969-12-31 19:00:00.000000000 -0500
+@@ -1,40 +0,0 @@
+-KERNEL THREADS
+-
+-
+-Freezer
+-
+-Upon entering a suspended state the system will freeze all
+-tasks. This is done by delivering pseudosignals. This affects
+-kernel threads, too. To successfully freeze a kernel thread
+-the thread has to check for the pseudosignal and enter the
+-refrigerator. Code to do this looks like this:
+-
+- do {
+- hub_events();
+- wait_event_interruptible(khubd_wait, !list_empty(&hub_event_list));
+- try_to_freeze();
+- } while (!signal_pending(current));
+-
+-from drivers/usb/core/hub.c::hub_thread()
+-
+-
+-The Unfreezable
+-
+-Some kernel threads however, must not be frozen. The kernel must
+-be able to finish pending IO operations and later on be able to
+-write the memory image to disk. Kernel threads needed to do IO
+-must stay awake. Such threads must mark themselves unfreezable
+-like this:
+-
+- /*
+- * This thread doesn't need any user-level access,
+- * so get rid of all our resources.
+- */
+- daemonize("usb-storage");
+-
+- current->flags |= PF_NOFREEZE;
+-
+-from drivers/usb/storage/usb.c::usb_stor_control_thread()
+-
+-Such drivers are themselves responsible for staying quiet during
+-the actual snapshotting.
+diff -Nurb linux-2.6.22-570/Documentation/power/swsusp.txt linux-2.6.22-590/Documentation/power/swsusp.txt
+--- linux-2.6.22-570/Documentation/power/swsusp.txt 2007-07-08 19:32:17.000000000 -0400
++++ linux-2.6.22-590/Documentation/power/swsusp.txt 2008-01-29 22:12:30.000000000 -0500
+@@ -140,21 +140,11 @@
+ website, and not to the Linux Kernel Mailing List. We are working
+ toward merging suspend2 into the mainline kernel.
+
+-Q: A kernel thread must voluntarily freeze itself (call 'refrigerator').
+-I found some kernel threads that don't do it, and they don't freeze
+-so the system can't sleep. Is this a known behavior?
+-
+-A: All such kernel threads need to be fixed, one by one. Select the
+-place where the thread is safe to be frozen (no kernel semaphores
+-should be held at that point and it must be safe to sleep there), and
+-add:
+-
+- try_to_freeze();
+-
+-If the thread is needed for writing the image to storage, you should
+-instead set the PF_NOFREEZE process flag when creating the thread (and
+-be very careful).
++Q: What is the freezing of tasks and why are we using it?
+
++A: The freezing of tasks is a mechanism by which user space processes and some
++kernel threads are controlled during hibernation or system-wide suspend (on some
++architectures). See freezing-of-tasks.txt for details.
+
+ Q: What is the difference between "platform" and "shutdown"?
+
+diff -Nurb linux-2.6.22-570/Documentation/scsi/scsi_fc_transport.txt linux-2.6.22-590/Documentation/scsi/scsi_fc_transport.txt
+--- linux-2.6.22-570/Documentation/scsi/scsi_fc_transport.txt 1969-12-31 19:00:00.000000000 -0500
++++ linux-2.6.22-590/Documentation/scsi/scsi_fc_transport.txt 2008-01-29 22:12:30.000000000 -0500
+@@ -0,0 +1,450 @@
++ SCSI FC Tansport
++ =============================================
++
++Date: 4/12/2007
++Kernel Revisions for features:
++ rports : <>
++ vports : 2.6.22 (? TBD)
++
++
++Introduction
++============
++This file documents the features and components of the SCSI FC Transport.
++It also provides documents the API between the transport and FC LLDDs.
++The FC transport can be found at:
++ drivers/scsi/scsi_transport_fc.c
++ include/scsi/scsi_transport_fc.h
++ include/scsi/scsi_netlink_fc.h
++
++This file is found at Documentation/scsi/scsi_fc_transport.txt
++
++
++FC Remote Ports (rports)
++========================================================================
++<< To Be Supplied >>
++
++
++FC Virtual Ports (vports)
++========================================================================
++
++Overview:
++-------------------------------
++
++ New FC standards have defined mechanisms which allows for a single physical
++ port to appear on as multiple communication ports. Using the N_Port Id
++ Virtualization (NPIV) mechanism, a point-to-point connection to a Fabric
++ can be assigned more than 1 N_Port_ID. Each N_Port_ID appears as a
++ separate port to other endpoints on the fabric, even though it shares one
++ physical link to the switch for communication. Each N_Port_ID can have a
++ unique view of the fabric based on fabric zoning and array lun-masking
++ (just like a normal non-NPIV adapter). Using the Virtual Fabric (VF)
++ mechanism, adding a fabric header to each frame allows the port to
++ interact with the Fabric Port to join multiple fabrics. The port will
++ obtain an N_Port_ID on each fabric it joins. Each fabric will have its
++ own unique view of endpoints and configuration parameters. NPIV may be
++ used together with VF so that the port can obtain multiple N_Port_IDs
++ on each virtual fabric.
++
++ The FC transport is now recognizing a new object - a vport. A vport is
++ an entity that has a world-wide unique World Wide Port Name (wwpn) and
++ World Wide Node Name (wwnn). The transport also allows for the FC4's to
++ be specified for the vport, with FCP_Initiator being the primary role
++ expected. Once instantiated by one of the above methods, it will have a
++ distinct N_Port_ID and view of fabric endpoints and storage entities.
++ The fc_host associated with the physical adapter will export the ability
++ to create vports. The transport will create the vport object within the
++ Linux device tree, and instruct the fc_host's driver to instantiate the
++ virtual port. Typically, the driver will create a new scsi_host instance
++ on the vport, resulting in a unique namespace for the vport.
++ Thus, whether a FC port is based on a physical port or on a virtual port,
++ each will appear as a unique scsi_host with its own target and lun space.
++
++ Note: At this time, the transport is written to create only NPIV-based
++ vports. However, consideration was given to VF-based vports and it
++ should be a minor change to add support if needed. The remaining
++ discussion will concentrate on NPIV.
++
++ Note: World Wide Name assignment (and uniqueness guarantees) are left
++ up to an administrative entity controling the vport. For example,
++ if vports are to be associated with virtual machines, a XEN mgmt
++ utility would be responsible for creating wwpn/wwnn's for the vport,
++ using it's own naming authority and OUI. (Note: it already does this
++ for virtual MAC addresses).
++
++
++Device Trees and Vport Objects:
++-------------------------------
++
++ Today, the device tree typically contains the scsi_host object,
++ with rports and scsi target objects underneath it. Currently the FC
++ transport creates the vport object and places it under the scsi_host
++ object corresponding to the physical adapter. The LLDD will allocate
++ a new scsi_host for the vport and link it's object under the vport.
++ The remainder of the tree under the vports scsi_host is the same
++ as the non-NPIV case. The transport is written currently to easily
++ allow the parent of the vport to be something other than the scsi_host.
++ This could be used in the future to link the object onto a vm-specific
++ device tree. If the vport's parent is not the physical port's scsi_host,
++ a symbolic link to the vport object will be placed in the physical
++ port's scsi_host.
++
++ Here's what to expect in the device tree :
++ The typical Physical Port's Scsi_Host:
++ /sys/devices/.../host17/
++ and it has the typical decendent tree:
++ /sys/devices/.../host17/rport-17:0-0/target17:0:0/17:0:0:0:
++ and then the vport is created on the Physical Port:
++ /sys/devices/.../host17/vport-17:0-0
++ and the vport's Scsi_Host is then created:
++ /sys/devices/.../host17/vport-17:0-0/host18
++ and then the rest of the tree progresses, such as:
++ /sys/devices/.../host17/vport-17:0-0/host18/rport-18:0-0/target18:0:0/18:0:0:0:
++
++ Here's what to expect in the sysfs tree :
++ scsi_hosts:
++ /sys/class/scsi_host/host17 physical port's scsi_host
++ /sys/class/scsi_host/host18 vport's scsi_host
++ fc_hosts:
++ /sys/class/fc_host/host17 physical port's fc_host
++ /sys/class/fc_host/host18 vport's fc_host
++ fc_vports:
++ /sys/class/fc_vports/vport-17:0-0 the vport's fc_vport
++ fc_rports:
++ /sys/class/fc_remote_ports/rport-17:0-0 rport on the physical port
++ /sys/class/fc_remote_ports/rport-18:0-0 rport on the vport
++
++
++Vport Attributes:
++-------------------------------
++
++ The new fc_vport class object has the following attributes
++
++ node_name: Read_Only
++ The WWNN of the vport
++
++ port_name: Read_Only
++ The WWPN of the vport
++
++ roles: Read_Only
++ Indicates the FC4 roles enabled on the vport.
++
++ symbolic_name: Read_Write
++ A string, appended to the driver's symbolic port name string, which
++ is registered with the switch to identify the vport. For example,
++ a hypervisor could set this string to "Xen Domain 2 VM 5 Vport 2",
++ and this set of identifiers can be seen on switch management screens
++ to identify the port.
++
++ vport_delete: Write_Only
++ When written with a "1", will tear down the vport.
++
++ vport_disable: Write_Only
++ When written with a "1", will transition the vport to a disabled.
++ state. The vport will still be instantiated with the Linux kernel,
++ but it will not be active on the FC link.
++ When written with a "0", will enable the vport.
++
++ vport_last_state: Read_Only
++ Indicates the previous state of the vport. See the section below on
++ "Vport States".
++
++ vport_state: Read_Only
++ Indicates the state of the vport. See the section below on
++ "Vport States".
++
++ vport_type: Read_Only
++ Reflects the FC mechanism used to create the virtual port.
++ Only NPIV is supported currently.
++
++
++ For the fc_host class object, the following attributes are added for vports:
++
++ max_npiv_vports: Read_Only
++ Indicates the maximum number of NPIV-based vports that the
++ driver/adapter can support on the fc_host.
++
++ npiv_vports_inuse: Read_Only
++ Indicates how many NPIV-based vports have been instantiated on the
++ fc_host.
++
++ vport_create: Write_Only
++ A "simple" create interface to instantiate a vport on an fc_host.
++ A ":" string is written to the attribute. The transport
++ then instantiates the vport object and calls the LLDD to create the
++ vport with the role of FCP_Initiator. Each WWN is specified as 16
++ hex characters and may *not* contain any prefixes (e.g. 0x, x, etc).
++
++ vport_delete: Write_Only
++ A "simple" delete interface to teardown a vport. A ":"
++ string is written to the attribute. The transport will locate the
++ vport on the fc_host with the same WWNs and tear it down. Each WWN
++ is specified as 16 hex characters and may *not* contain any prefixes
++ (e.g. 0x, x, etc).
++
++
++Vport States:
++-------------------------------
++
++ Vport instantiation consists of two parts:
++ - Creation with the kernel and LLDD. This means all transport and
++ driver data structures are built up, and device objects created.
++ This is equivalent to a driver "attach" on an adapter, which is
++ independent of the adapter's link state.
++ - Instantiation of the vport on the FC link via ELS traffic, etc.
++ This is equivalent to a "link up" and successfull link initialization.
++ Futher information can be found in the interfaces section below for
++ Vport Creation.
++
++ Once a vport has been instantiated with the kernel/LLDD, a vport state
++ can be reported via the sysfs attribute. The following states exist:
++
++ FC_VPORT_UNKNOWN - Unknown
++ An temporary state, typically set only while the vport is being
++ instantiated with the kernel and LLDD.
++
++ FC_VPORT_ACTIVE - Active
++ The vport has been successfully been created on the FC link.
++ It is fully functional.
++
++ FC_VPORT_DISABLED - Disabled
++ The vport instantiated, but "disabled". The vport is not instantiated
++ on the FC link. This is equivalent to a physical port with the
++ link "down".
++
++ FC_VPORT_LINKDOWN - Linkdown
++ The vport is not operational as the physical link is not operational.
++
++ FC_VPORT_INITIALIZING - Initializing
++ The vport is in the process of instantiating on the FC link.
++ The LLDD will set this state just prior to starting the ELS traffic
++ to create the vport. This state will persist until the vport is
++ successfully created (state becomes FC_VPORT_ACTIVE) or it fails
++ (state is one of the values below). As this state is transitory,
++ it will not be preserved in the "vport_last_state".
++
++ FC_VPORT_NO_FABRIC_SUPP - No Fabric Support
++ The vport is not operational. One of the following conditions were
++ encountered:
++ - The FC topology is not Point-to-Point
++ - The FC port is not connected to an F_Port
++ - The F_Port has indicated that NPIV is not supported.
++
++ FC_VPORT_NO_FABRIC_RSCS - No Fabric Resources
++ The vport is not operational. The Fabric failed FDISC with a status
++ indicating that it does not have sufficient resources to complete
++ the operation.
++
++ FC_VPORT_FABRIC_LOGOUT - Fabric Logout
++ The vport is not operational. The Fabric has LOGO'd the N_Port_ID
++ associated with the vport.
++
++ FC_VPORT_FABRIC_REJ_WWN - Fabric Rejected WWN
++ The vport is not operational. The Fabric failed FDISC with a status
++ indicating that the WWN's are not valid.
++
++ FC_VPORT_FAILED - VPort Failed
++ The vport is not operational. This is a catchall for all other
++ error conditions.
++
++
++ The following state table indicates the different state transitions:
++
++ State Event New State
++ --------------------------------------------------------------------
++ n/a Initialization Unknown
++ Unknown: Link Down Linkdown
++ Link Up & Loop No Fabric Support
++ Link Up & no Fabric No Fabric Support
++ Link Up & FLOGI response No Fabric Support
++ indicates no NPIV support
++ Link Up & FDISC being sent Initializing
++ Disable request Disable
++ Linkdown: Link Up Unknown
++ Initializing: FDISC ACC Active
++ FDISC LS_RJT w/ no resources No Fabric Resources
++ FDISC LS_RJT w/ invalid Fabric Rejected WWN
++ pname or invalid nport_id
++ FDISC LS_RJT failed for Vport Failed
++ other reasons
++ Link Down Linkdown
++ Disable request Disable
++ Disable: Enable request Unknown
++ Active: LOGO received from fabric Fabric Logout
++ Link Down Linkdown
++ Disable request Disable
++ Fabric Logout: Link still up Unknown
++
++ The following 4 error states all have the same transitions:
++ No Fabric Support:
++ No Fabric Resources:
++ Fabric Rejected WWN:
++ Vport Failed:
++ Disable request Disable
++ Link goes down Linkdown
++
++
++Transport <-> LLDD Interfaces :
++-------------------------------
++
++Vport support by LLDD:
++
++ The LLDD indicates support for vports by supplying a vport_create()
++ function in the transport template. The presense of this function will
++ cause the creation of the new attributes on the fc_host. As part of
++ the physical port completing its initialization relative to the
++ transport, it should set the max_npiv_vports attribute to indicate the
++ maximum number of vports the driver and/or adapter supports.
++
++
++Vport Creation:
++
++ The LLDD vport_create() syntax is:
++
++ int vport_create(struct fc_vport *vport, bool disable)
++
++ where:
++ vport: Is the newly allocated vport object
++ disable: If "true", the vport is to be created in a disabled stated.
++ If "false", the vport is to be enabled upon creation.
++
++ When a request is made to create a new vport (via sgio/netlink, or the
++ vport_create fc_host attribute), the transport will validate that the LLDD
++ can support another vport (e.g. max_npiv_vports > npiv_vports_inuse).
++ If not, the create request will be failed. If space remains, the transport
++ will increment the vport count, create the vport object, and then call the
++ LLDD's vport_create() function with the newly allocated vport object.
++
++ As mentioned above, vport creation is divided into two parts:
++ - Creation with the kernel and LLDD. This means all transport and
++ driver data structures are built up, and device objects created.
++ This is equivalent to a driver "attach" on an adapter, which is
++ independent of the adapter's link state.
++ - Instantiation of the vport on the FC link via ELS traffic, etc.
++ This is equivalent to a "link up" and successfull link initialization.
++
++ The LLDD's vport_create() function will not synchronously wait for both
++ parts to be fully completed before returning. It must validate that the
++ infrastructure exists to support NPIV, and complete the first part of
++ vport creation (data structure build up) before returning. We do not
++ hinge vport_create() on the link-side operation mainly because:
++ - The link may be down. It is not a failure if it is. It simply
++ means the vport is in an inoperable state until the link comes up.
++ This is consistent with the link bouncing post vport creation.
++ - The vport may be created in a disabled state.
++ - This is consistent with a model where: the vport equates to a
++ FC adapter. The vport_create is synonymous with driver attachment
++ to the adapter, which is independent of link state.
++
++ Note: special error codes have been defined to delineate infrastructure
++ failure cases for quicker resolution.
++
++ The expected behavior for the LLDD's vport_create() function is:
++ - Validate Infrastructure:
++ - If the driver or adapter cannot support another vport, whether
++ due to improper firmware, (a lie about) max_npiv, or a lack of
++ some other resource - return VPCERR_UNSUPPORTED.
++ - If the driver validates the WWN's against those already active on
++ the adapter and detects an overlap - return VPCERR_BAD_WWN.
++ - If the driver detects the topology is loop, non-fabric, or the
++ FLOGI did not support NPIV - return VPCERR_NO_FABRIC_SUPP.
++ - Allocate data structures. If errors are encountered, such as out
++ of memory conditions, return the respective negative Exxx error code.
++ - If the role is FCP Initiator, the LLDD is to :
++ - Call scsi_host_alloc() to allocate a scsi_host for the vport.
++ - Call scsi_add_host(new_shost, &vport->dev) to start the scsi_host
++ and bind it as a child of the vport device.
++ - Initializes the fc_host attribute values.
++ - Kick of further vport state transitions based on the disable flag and
++ link state - and return success (zero).
++
++ LLDD Implementers Notes:
++ - It is suggested that there be a different fc_function_templates for
++ the physical port and the virtual port. The physical port's template
++ would have the vport_create, vport_delete, and vport_disable functions,
++ while the vports would not.
++ - It is suggested that there be different scsi_host_templates
++ for the physical port and virtual port. Likely, there are driver
++ attributes, embedded into the scsi_host_template, that are applicable
++ for the physical port only (link speed, topology setting, etc). This
++ ensures that the attributes are applicable to the respective scsi_host.
++
++
++Vport Disable/Enable:
++
++ The LLDD vport_disable() syntax is:
++
++ int vport_disable(struct fc_vport *vport, bool disable)
++
++ where:
++ vport: Is vport to to be enabled or disabled
++ disable: If "true", the vport is to be disabled.
++ If "false", the vport is to be enabled.
++
++ When a request is made to change the disabled state on a vport, the
++ transport will validate the request against the existing vport state.
++ If the request is to disable and the vport is already disabled, the
++ request will fail. Similarly, if the request is to enable, and the
++ vport is not in a disabled state, the request will fail. If the request
++ is valid for the vport state, the transport will call the LLDD to
++ change the vport's state.
++
++ Within the LLDD, if a vport is disabled, it remains instantiated with
++ the kernel and LLDD, but it is not active or visible on the FC link in
++ any way. (see Vport Creation and the 2 part instantiation discussion).
++ The vport will remain in this state until it is deleted or re-enabled.
++ When enabling a vport, the LLDD reinstantiates the vport on the FC
++ link - essentially restarting the LLDD statemachine (see Vport States
++ above).
++
++
++Vport Deletion:
++
++ The LLDD vport_delete() syntax is:
++
++ int vport_delete(struct fc_vport *vport)
++
++ where:
++ vport: Is vport to delete
++
++ When a request is made to delete a vport (via sgio/netlink, or via the
++ fc_host or fc_vport vport_delete attributes), the transport will call
++ the LLDD to terminate the vport on the FC link, and teardown all other
++ datastructures and references. If the LLDD completes successfully,
++ the transport will teardown the vport objects and complete the vport
++ removal. If the LLDD delete request fails, the vport object will remain,
++ but will be in an indeterminate state.
++
++ Within the LLDD, the normal code paths for a scsi_host teardown should
++ be followed. E.g. If the vport has a FCP Initiator role, the LLDD
++ will call fc_remove_host() for the vports scsi_host, followed by
++ scsi_remove_host() and scsi_host_put() for the vports scsi_host.
++
++
++Other:
++ fc_host port_type attribute:
++ There is a new fc_host port_type value - FC_PORTTYPE_NPIV. This value
++ must be set on all vport-based fc_hosts. Normally, on a physical port,
++ the port_type attribute would be set to NPORT, NLPORT, etc based on the
++ topology type and existence of the fabric. As this is not applicable to
++ a vport, it makes more sense to report the FC mechanism used to create
++ the vport.
++
++ Driver unload:
++ FC drivers are required to call fc_remove_host() prior to calling
++ scsi_remove_host(). This allows the fc_host to tear down all remote
++ ports prior the scsi_host being torn down. The fc_remove_host() call
++ was updated to remove all vports for the fc_host as well.
++
++
++Credits
++=======
++The following people have contributed to this document:
+
-+localver-full = $(localver)$(localver-auto)
-+
-+# Store (new) KERNELRELASE string in include/config/kernel.release
-+kernelrelease = $(KERNELVERSION)$(localver-full)
-+include/config/kernel.release: include/config/auto.conf FORCE
-+ $(Q)rm -f $@
-+ $(Q)echo $(kernelrelease) > $@
-+
-+
-+# Things we need to do before we recursively start building the kernel
-+# or the modules are listed in "prepare".
-+# A multi level approach is used. prepareN is processed before prepareN-1.
-+# archprepare is used in arch Makefiles and when processed asm symlink,
-+# version.h and scripts_basic is processed / created.
-+
-+# Listed in dependency order
-+PHONY += prepare archprepare prepare0 prepare1 prepare2 prepare3
-+
-+# 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
-+prepare3: include/config/kernel.release
-+ifneq ($(KBUILD_SRC),)
-+ @echo ' Using $(srctree) as source for kernel'
-+ $(Q)if [ -f $(srctree)/.config -o -d $(srctree)/include/config ]; then \
-+ echo " $(srctree) is not clean, please run 'make mrproper'";\
-+ echo " in the '$(srctree)' directory.";\
-+ /bin/false; \
-+ fi;
-+ $(Q)if [ ! -d include2 ]; then mkdir -p include2; fi;
-+ $(Q)ln -fsn $(srctree)/include/asm-$(ARCH) include2/asm
-+endif
+
-+# prepare2 creates a makefile if using a separate output directory
-+prepare2: prepare3 outputmakefile
+
-+prepare1: prepare2 include/linux/version.h include/linux/utsrelease.h \
-+ include/asm include/config/auto.conf
-+ifneq ($(KBUILD_MODULES),)
-+ $(Q)mkdir -p $(MODVERDIR)
-+ $(Q)rm -f $(MODVERDIR)/*
-+endif
+
-+archprepare: prepare1 scripts_basic
+
-+prepare0: archprepare FORCE
-+ $(Q)$(MAKE) $(build)=.
-+ $(Q)$(MAKE) $(build)=. missing-syscalls
+
-+# All the preparing..
-+prepare: prepare0
++James Smart
++james.smart@emulex.com
+
-+# Leave this as default for preprocessing vmlinux.lds.S, which is now
-+# done in arch/$(ARCH)/kernel/Makefile
+diff -Nurb linux-2.6.22-570/Documentation/sysctl/kernel.txt linux-2.6.22-590/Documentation/sysctl/kernel.txt
+--- linux-2.6.22-570/Documentation/sysctl/kernel.txt 2007-07-08 19:32:17.000000000 -0400
++++ linux-2.6.22-590/Documentation/sysctl/kernel.txt 2008-01-29 22:12:30.000000000 -0500
+@@ -29,6 +29,7 @@
+ - java-interpreter [ binfmt_java, obsolete ]
+ - kstack_depth_to_print [ X86 only ]
+ - l2cr [ PPC only ]
++- mmap_min_addr
+ - modprobe ==> Documentation/kmod.txt
+ - msgmax
+ - msgmnb
+@@ -178,6 +179,19 @@
+
+ ==============================================================
+
++mmap_min_addr
+
-+export CPPFLAGS_vmlinux.lds += -P -C -U$(ARCH)
++This file indicates the amount of address space which a user process will be
++restricted from mmaping. Since kernel null dereference bugs could
++accidentally operate based on the information in the first couple of pages of
++memory userspace processes should not be allowed to write to them. By default
++this value is set to 0 and no protections will be enforced by the security
++module. Setting this value to something like 64k will allow the vast majority
++of applications to work correctly and provide defense in depth against future
++potential kernel bugs.
+
-+# FIXME: The asm symlink changes when $(ARCH) changes. That's
-+# hard to detect, but I suppose "make mrproper" is a good idea
-+# before switching between archs anyway.
++==============================================================
+
-+include/asm:
-+ @echo ' SYMLINK $@ -> include/asm-$(ARCH)'
-+ $(Q)if [ ! -d include ]; then mkdir -p include; fi;
-+ @ln -fsn asm-$(ARCH) $@
+ osrelease, ostype & version:
+
+ # cat osrelease
+diff -Nurb linux-2.6.22-570/Documentation/sysfs-rules.txt linux-2.6.22-590/Documentation/sysfs-rules.txt
+--- linux-2.6.22-570/Documentation/sysfs-rules.txt 1969-12-31 19:00:00.000000000 -0500
++++ linux-2.6.22-590/Documentation/sysfs-rules.txt 2008-01-29 22:12:30.000000000 -0500
+@@ -0,0 +1,166 @@
++Rules on how to access information in the Linux kernel sysfs
++
++The kernel exported sysfs exports internal kernel implementation-details
++and depends on internal kernel structures and layout. It is agreed upon
++by the kernel developers that the Linux kernel does not provide a stable
++internal API. As sysfs is a direct export of kernel internal
++structures, the sysfs interface can not provide a stable interface eighter,
++it may always change along with internal kernel changes.
++
++To minimize the risk of breaking users of sysfs, which are in most cases
++low-level userspace applications, with a new kernel release, the users
++of sysfs must follow some rules to use an as abstract-as-possible way to
++access this filesystem. The current udev and HAL programs already
++implement this and users are encouraged to plug, if possible, into the
++abstractions these programs provide instead of accessing sysfs
++directly.
++
++But if you really do want or need to access sysfs directly, please follow
++the following rules and then your programs should work with future
++versions of the sysfs interface.
++
++- Do not use libsysfs
++ It makes assumptions about sysfs which are not true. Its API does not
++ offer any abstraction, it exposes all the kernel driver-core
++ implementation details in its own API. Therefore it is not better than
++ reading directories and opening the files yourself.
++ Also, it is not actively maintained, in the sense of reflecting the
++ current kernel-development. The goal of providing a stable interface
++ to sysfs has failed, it causes more problems, than it solves. It
++ violates many of the rules in this document.
++
++- sysfs is always at /sys
++ Parsing /proc/mounts is a waste of time. Other mount points are a
++ system configuration bug you should not try to solve. For test cases,
++ possibly support a SYSFS_PATH environment variable to overwrite the
++ applications behavior, but never try to search for sysfs. Never try
++ to mount it, if you are not an early boot script.
++
++- devices are only "devices"
++ There is no such thing like class-, bus-, physical devices,
++ interfaces, and such that you can rely on in userspace. Everything is
++ just simply a "device". Class-, bus-, physical, ... types are just
++ kernel implementation details, which should not be expected by
++ applications that look for devices in sysfs.
++
++ The properties of a device are:
++ o devpath (/devices/pci0000:00/0000:00:1d.1/usb2/2-2/2-2:1.0)
++ - identical to the DEVPATH value in the event sent from the kernel
++ at device creation and removal
++ - the unique key to the device at that point in time
++ - the kernels path to the device-directory without the leading
++ /sys, and always starting with with a slash
++ - all elements of a devpath must be real directories. Symlinks
++ pointing to /sys/devices must always be resolved to their real
++ target, and the target path must be used to access the device.
++ That way the devpath to the device matches the devpath of the
++ kernel used at event time.
++ - using or exposing symlink values as elements in a devpath string
++ is a bug in the application
++
++ o kernel name (sda, tty, 0000:00:1f.2, ...)
++ - a directory name, identical to the last element of the devpath
++ - applications need to handle spaces and characters like '!' in
++ the name
++
++ o subsystem (block, tty, pci, ...)
++ - simple string, never a path or a link
++ - retrieved by reading the "subsystem"-link and using only the
++ last element of the target path
++
++ o driver (tg3, ata_piix, uhci_hcd)
++ - a simple string, which may contain spaces, never a path or a
++ link
++ - it is retrieved by reading the "driver"-link and using only the
++ last element of the target path
++ - devices which do not have "driver"-link, just do not have a
++ driver; copying the driver value in a child device context, is a
++ bug in the application
++
++ o attributes
++ - the files in the device directory or files below a subdirectories
++ of the same device directory
++ - accessing attributes reached by a symlink pointing to another device,
++ like the "device"-link, is a bug in the application
++
++ Everything else is just a kernel driver-core implementation detail,
++ that should not be assumed to be stable across kernel releases.
++
++- Properties of parent devices never belong into a child device.
++ Always look at the parent devices themselves for determining device
++ context properties. If the device 'eth0' or 'sda' does not have a
++ "driver"-link, then this device does not have a driver. Its value is empty.
++ Never copy any property of the parent-device into a child-device. Parent
++ device-properties may change dynamically without any notice to the
++ child device.
++
++- Hierarchy in a single device-tree
++ There is only one valid place in sysfs where hierarchy can be examined
++ and this is below: /sys/devices.
++ It is planned, that all device directories will end up in the tree
++ below this directory.
++
++- Classification by subsystem
++ There are currently three places for classification of devices:
++ /sys/block, /sys/class and /sys/bus. It is planned that these will
++ not contain any device-directories themselves, but only flat lists of
++ symlinks pointing to the unified /sys/devices tree.
++ All three places have completely different rules on how to access
++ device information. It is planned to merge all three
++ classification-directories into one place at /sys/subsystem,
++ following the layout of the bus-directories. All buses and
++ classes, including the converted block-subsystem, will show up
++ there.
++ The devices belonging to a subsystem will create a symlink in the
++ "devices" directory at /sys/subsystem//devices.
++
++ If /sys/subsystem exists, /sys/bus, /sys/class and /sys/block can be
++ ignored. If it does not exist, you have always to scan all three
++ places, as the kernel is free to move a subsystem from one place to
++ the other, as long as the devices are still reachable by the same
++ subsystem name.
++
++ Assuming /sys/class/ and /sys/bus/, or
++ /sys/block and /sys/class/block are not interchangeable, is a bug in
++ the application.
++
++- Block
++ The converted block-subsystem at /sys/class/block, or
++ /sys/subsystem/block will contain the links for disks and partitions
++ at the same level, never in a hierarchy. Assuming the block-subsytem to
++ contain only disks and not partition-devices in the same flat list is
++ a bug in the application.
++
++- "device"-link and :-links
++ Never depend on the "device"-link. The "device"-link is a workaround
++ for the old layout, where class-devices are not created in
++ /sys/devices/ like the bus-devices. If the link-resolving of a
++ device-directory does not end in /sys/devices/, you can use the
++ "device"-link to find the parent devices in /sys/devices/. That is the
++ single valid use of the "device"-link, it must never appear in any
++ path as an element. Assuming the existence of the "device"-link for
++ a device in /sys/devices/ is a bug in the application.
++ Accessing /sys/class/net/eth0/device is a bug in the application.
++
++ Never depend on the class-specific links back to the /sys/class
++ directory. These links are also a workaround for the design mistake
++ that class-devices are not created in /sys/devices. If a device
++ directory does not contain directories for child devices, these links
++ may be used to find the child devices in /sys/class. That is the single
++ valid use of these links, they must never appear in any path as an
++ element. Assuming the existence of these links for devices which are
++ real child device directories in the /sys/devices tree, is a bug in
++ the application.
++
++ It is planned to remove all these links when when all class-device
++ directories live in /sys/devices.
++
++- Position of devices along device chain can change.
++ Never depend on a specific parent device position in the devpath,
++ or the chain of parent devices. The kernel is free to insert devices into
++ the chain. You must always request the parent device you are looking for
++ by its subsystem value. You need to walk up the chain until you find
++ the device that matches the expected subsystem. Depending on a specific
++ position of a parent device, or exposing relative paths, using "../" to
++ access the chain of parents, is a bug in the application.
++
+diff -Nurb linux-2.6.22-570/MAINTAINERS linux-2.6.22-590/MAINTAINERS
+--- linux-2.6.22-570/MAINTAINERS 2007-07-08 19:32:17.000000000 -0400
++++ linux-2.6.22-590/MAINTAINERS 2008-01-29 22:12:30.000000000 -0500
+@@ -232,15 +232,15 @@
+ S: Supported
+
+ ACPI BATTERY DRIVERS
+-P: Vladimir P. Lebedev
+-M: vladimir.p.lebedev@intel.com
++P: Alexey Starikovskiy
++M: astarikovskiy@suse.de
+ L: linux-acpi@vger.kernel.org
+ W: http://acpi.sourceforge.net/
+ S: Supported
+
+ ACPI EC DRIVER
+ P: Alexey Starikovskiy
+-M: alexey.y.starikovskiy@linux.intel.com
++M: astarikovskiy@suse.de
+ L: linux-acpi@vger.kernel.org
+ W: http://acpi.sourceforge.net/
+ S: Supported
+@@ -2127,6 +2127,15 @@
+ L: kexec@lists.infradead.org
+ S: Maintained
+
++KGDB
++P: Jason Wessel
++M: jason.wessel@windriver.com
++P: Amit S. Kale
++M: amitkale@linsyssoft.com
++W: http://sourceforge.net/projects/kgdb
++L: kgdb-bugreport@lists.sourceforge.net
++S: Maintained
+
-+# Generate some files
-+# ---------------------------------------------------------------------------
+ KPROBES
+ P: Prasanna S Panchamukhi
+ M: prasanna@in.ibm.com
+@@ -3593,6 +3602,15 @@
+ W: http://www.kernel.dk
+ S: Maintained
+
++UNIONFS
++P: Erez Zadok
++M: ezk@cs.sunysb.edu
++P: Josef "Jeff" Sipek
++M: jsipek@cs.sunysb.edu
++L: unionfs@filesystems.org
++W: http://unionfs.filesystems.org
++S: Maintained
+
-+# KERNELRELEASE can change from a few different places, meaning version.h
-+# needs to be updated, so this check is forced on all builds
-+
-+uts_len := 64
-+define filechk_utsrelease.h
-+ if [ `echo -n "$(KERNELRELEASE)" | wc -c ` -gt $(uts_len) ]; then \
-+ echo '"$(KERNELRELEASE)" exceeds $(uts_len) characters' >&2; \
-+ exit 1; \
-+ fi; \
-+ (echo \#define UTS_RELEASE \"$(KERNELRELEASE)\";)
-+endef
-+
-+define filechk_version.h
-+ (echo \#define LINUX_VERSION_CODE $(shell \
-+ expr $(VERSION) \* 65536 + $(PATCHLEVEL) \* 256 + $(SUBLEVEL)); \
-+ echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))';)
-+endef
-+
-+include/linux/version.h: $(srctree)/Makefile FORCE
-+ $(call filechk,version.h)
-+
-+include/linux/utsrelease.h: include/config/kernel.release FORCE
-+ $(call filechk,utsrelease.h)
-+
-+# ---------------------------------------------------------------------------
-+
-+PHONY += depend dep
-+depend dep:
-+ @echo '*** Warning: make $@ is unnecessary now.'
-+
-+# ---------------------------------------------------------------------------
-+# Kernel headers
-+INSTALL_HDR_PATH=$(objtree)/usr
-+export INSTALL_HDR_PATH
-+
-+HDRARCHES=$(filter-out generic,$(patsubst $(srctree)/include/asm-%/Kbuild,%,$(wildcard $(srctree)/include/asm-*/Kbuild)))
-+
-+PHONY += headers_install_all
-+headers_install_all: include/linux/version.h scripts_basic FORCE
-+ $(Q)$(MAKE) $(build)=scripts scripts/unifdef
-+ $(Q)for arch in $(HDRARCHES); do \
-+ $(MAKE) ARCH=$$arch -f $(srctree)/scripts/Makefile.headersinst obj=include BIASMDIR=-bi-$$arch ;\
-+ done
-+
-+PHONY += headers_install
-+headers_install: include/linux/version.h scripts_basic FORCE
-+ @if [ ! -r $(srctree)/include/asm-$(ARCH)/Kbuild ]; then \
-+ echo '*** Error: Headers not exportable for this architecture ($(ARCH))'; \
-+ exit 1 ; fi
-+ $(Q)$(MAKE) $(build)=scripts scripts/unifdef
-+ $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.headersinst obj=include
-+
-+PHONY += headers_check_all
-+headers_check_all: headers_install_all
-+ $(Q)for arch in $(HDRARCHES); do \
-+ $(MAKE) ARCH=$$arch -f $(srctree)/scripts/Makefile.headersinst obj=include BIASMDIR=-bi-$$arch HDRCHECK=1 ;\
-+ done
-+
-+PHONY += headers_check
-+headers_check: headers_install
-+ $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.headersinst obj=include HDRCHECK=1
-+
-+# ---------------------------------------------------------------------------
-+# Modules
-+
-+ifdef CONFIG_MODULES
-+
-+# By default, build modules as well
-+
-+all: modules
-+
-+# Build modules
-+
-+PHONY += modules
-+modules: $(vmlinux-dirs) $(if $(KBUILD_BUILTIN),vmlinux)
-+ @echo ' Building modules, stage 2.';
-+ $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost
-+
-+
-+# Target to prepare building external modules
-+PHONY += modules_prepare
-+modules_prepare: prepare scripts
-+
-+# Target to install modules
-+PHONY += modules_install
-+modules_install: _modinst_ _modinst_post
-+
-+PHONY += _modinst_
-+_modinst_:
-+ @if [ -z "`$(DEPMOD) -V 2>/dev/null | grep module-init-tools`" ]; then \
-+ echo "Warning: you may need to install module-init-tools"; \
-+ echo "See http://www.codemonkey.org.uk/docs/post-halloween-2.6.txt";\
-+ sleep 1; \
-+ fi
-+ @rm -rf $(MODLIB)/kernel
-+ @rm -f $(MODLIB)/source
-+ @mkdir -p $(MODLIB)/kernel
-+ @ln -s $(srctree) $(MODLIB)/source
-+ @if [ ! $(objtree) -ef $(MODLIB)/build ]; then \
-+ rm -f $(MODLIB)/build ; \
-+ ln -s $(objtree) $(MODLIB)/build ; \
-+ fi
-+ $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modinst
-+
-+# If System.map exists, run depmod. This deliberately does not have a
-+# dependency on System.map since that would run the dependency tree on
-+# vmlinux. This depmod is only for convenience to give the initial
-+# boot a modules.dep even before / is mounted read-write. However the
-+# boot script depmod is the master version.
-+ifeq "$(strip $(INSTALL_MOD_PATH))" ""
-+depmod_opts :=
-+else
-+depmod_opts := -b $(INSTALL_MOD_PATH) -r
-+endif
-+PHONY += _modinst_post
-+_modinst_post: _modinst_
-+ if [ -r System.map -a -x $(DEPMOD) ]; then $(DEPMOD) -ae -F System.map $(depmod_opts) $(KERNELRELEASE); fi
-+
-+else # CONFIG_MODULES
-+
-+# Modules not configured
-+# ---------------------------------------------------------------------------
-+
-+modules modules_install: FORCE
-+ @echo
-+ @echo "The present kernel configuration has modules disabled."
-+ @echo "Type 'make config' and enable loadable module support."
-+ @echo "Then build a kernel with module support enabled."
-+ @echo
-+ @exit 1
-+
-+endif # CONFIG_MODULES
-+
-+###
-+# Cleaning is done on three levels.
-+# make clean Delete most generated files
-+# Leave enough to build external modules
-+# make mrproper Delete the current configuration, and all generated files
-+# make distclean Remove editor backup files, patch leftover files and the like
-+
-+# Directories & files removed with 'make clean'
-+CLEAN_DIRS += $(MODVERDIR)
-+CLEAN_FILES += vmlinux System.map \
-+ .tmp_kallsyms* .tmp_version .tmp_vmlinux* .tmp_System.map
-+
-+# Directories & files removed with 'make mrproper'
-+MRPROPER_DIRS += include/config include2 usr/include
-+MRPROPER_FILES += .config .config.old include/asm .version .old_version \
-+ include/linux/autoconf.h include/linux/version.h \
-+ include/linux/utsrelease.h \
-+ Module.symvers tags TAGS cscope*
-+
-+# clean - Delete most, but leave enough to build external modules
-+#
-+clean: rm-dirs := $(CLEAN_DIRS)
-+clean: rm-files := $(CLEAN_FILES)
-+clean-dirs := $(addprefix _clean_,$(srctree) $(vmlinux-alldirs))
-+
-+PHONY += $(clean-dirs) clean archclean
-+$(clean-dirs):
-+ $(Q)$(MAKE) $(clean)=$(patsubst _clean_%,%,$@)
-+
-+clean: archclean $(clean-dirs)
-+ $(call cmd,rmdirs)
-+ $(call cmd,rmfiles)
-+ @find . $(RCS_FIND_IGNORE) \
-+ \( -name '*.[oas]' -o -name '*.ko' -o -name '.*.cmd' \
-+ -o -name '.*.d' -o -name '.*.tmp' -o -name '*.mod.c' \
-+ -o -name '*.symtypes' \) \
-+ -type f -print | xargs rm -f
-+
-+# mrproper - Delete all generated files, including .config
-+#
-+mrproper: rm-dirs := $(wildcard $(MRPROPER_DIRS))
-+mrproper: rm-files := $(wildcard $(MRPROPER_FILES))
-+mrproper-dirs := $(addprefix _mrproper_,Documentation/DocBook scripts)
-+
-+PHONY += $(mrproper-dirs) mrproper archmrproper
-+$(mrproper-dirs):
-+ $(Q)$(MAKE) $(clean)=$(patsubst _mrproper_%,%,$@)
-+
-+mrproper: clean archmrproper $(mrproper-dirs)
-+ $(call cmd,rmdirs)
-+ $(call cmd,rmfiles)
-+
-+# distclean
-+#
-+PHONY += distclean
-+
-+distclean: mrproper
-+ @find $(srctree) $(RCS_FIND_IGNORE) \
-+ \( -name '*.orig' -o -name '*.rej' -o -name '*~' \
-+ -o -name '*.bak' -o -name '#*#' -o -name '.*.orig' \
-+ -o -name '.*.rej' -o -size 0 \
-+ -o -name '*%' -o -name '.*.cmd' -o -name 'core' \) \
-+ -type f -print | xargs rm -f
-+
-+
-+# Packaging of the kernel to various formats
-+# ---------------------------------------------------------------------------
-+# rpm target kept for backward compatibility
-+package-dir := $(srctree)/scripts/package
-+
-+%pkg: include/config/kernel.release FORCE
-+ $(Q)$(MAKE) $(build)=$(package-dir) $@
-+rpm: include/config/kernel.release FORCE
-+ $(Q)$(MAKE) $(build)=$(package-dir) $@
-+
-+
-+# Brief documentation of the typical targets used
-+# ---------------------------------------------------------------------------
-+
-+boards := $(wildcard $(srctree)/arch/$(ARCH)/configs/*_defconfig)
-+boards := $(notdir $(boards))
-+
-+help:
-+ @echo 'Cleaning targets:'
-+ @echo ' clean - Remove most generated files but keep the config and'
-+ @echo ' enough build support to build external modules'
-+ @echo ' mrproper - Remove all generated files + config + various backup files'
-+ @echo ' distclean - mrproper + remove editor backup and patch files'
-+ @echo ''
-+ @echo 'Configuration targets:'
-+ @$(MAKE) -f $(srctree)/scripts/kconfig/Makefile help
-+ @echo ''
-+ @echo 'Other generic targets:'
-+ @echo ' all - Build all targets marked with [*]'
-+ @echo '* vmlinux - Build the bare kernel'
-+ @echo '* modules - Build all modules'
-+ @echo ' modules_install - Install all modules to INSTALL_MOD_PATH (default: /)'
-+ @echo ' dir/ - Build all files in dir and below'
-+ @echo ' dir/file.[ois] - Build specified target only'
-+ @echo ' dir/file.ko - Build module including final link'
-+ @echo ' rpm - Build a kernel as an RPM package'
-+ @echo ' tags/TAGS - Generate tags file for editors'
-+ @echo ' cscope - Generate cscope index'
-+ @echo ' kernelrelease - Output the release version string'
-+ @echo ' kernelversion - Output the version stored in Makefile'
-+ @if [ -r $(srctree)/include/asm-$(ARCH)/Kbuild ]; then \
-+ echo ' headers_install - Install sanitised kernel headers to INSTALL_HDR_PATH'; \
-+ echo ' (default: $(INSTALL_HDR_PATH))'; \
-+ fi
-+ @echo ''
-+ @echo 'Static analysers'
-+ @echo ' checkstack - Generate a list of stack hogs'
-+ @echo ' namespacecheck - Name space analysis on compiled kernel'
-+ @if [ -r $(srctree)/include/asm-$(ARCH)/Kbuild ]; then \
-+ echo ' headers_check - Sanity check on exported headers'; \
-+ fi
-+ @echo ''
-+ @echo 'Kernel packaging:'
-+ @$(MAKE) $(build)=$(package-dir) help
-+ @echo ''
-+ @echo 'Documentation targets:'
-+ @$(MAKE) -f $(srctree)/Documentation/DocBook/Makefile dochelp
-+ @echo ''
-+ @echo 'Architecture specific targets ($(ARCH)):'
-+ @$(if $(archhelp),$(archhelp),\
-+ echo ' No architecture specific help defined for $(ARCH)')
-+ @echo ''
-+ @$(if $(boards), \
-+ $(foreach b, $(boards), \
-+ printf " %-24s - Build for %s\\n" $(b) $(subst _defconfig,,$(b));) \
-+ echo '')
-+
-+ @echo ' make V=0|1 [targets] 0 => quiet build (default), 1 => verbose build'
-+ @echo ' make V=2 [targets] 2 => give reason for rebuild of target'
-+ @echo ' make O=dir [targets] Locate all output files in "dir", including .config'
-+ @echo ' make C=1 [targets] Check all c source with $$CHECK (sparse by default)'
-+ @echo ' make C=2 [targets] Force check of all c source with $$CHECK'
-+ @echo ''
-+ @echo 'Execute "make" or "make all" to build all targets marked with [*] '
-+ @echo 'For further info see the ./README file'
-+
-+
-+# Documentation targets
-+# ---------------------------------------------------------------------------
-+%docs: scripts_basic FORCE
-+ $(Q)$(MAKE) $(build)=Documentation/DocBook $@
-+
-+else # KBUILD_EXTMOD
-+
-+###
-+# External module support.
-+# When building external modules the kernel used as basis is considered
-+# read-only, and no consistency checks are made and the make
-+# system is not used on the basis kernel. If updates are required
-+# in the basis kernel ordinary make commands (without M=...) must
-+# be used.
-+#
-+# The following are the only valid targets when building external
-+# modules.
-+# make M=dir clean Delete all automatically generated files
-+# make M=dir modules Make all modules in specified dir
-+# make M=dir Same as 'make M=dir modules'
-+# make M=dir modules_install
-+# Install the modules built in the module directory
-+# Assumes install directory is already created
-+
-+# We are always building modules
-+KBUILD_MODULES := 1
-+PHONY += crmodverdir
-+crmodverdir:
-+ $(Q)mkdir -p $(MODVERDIR)
-+ $(Q)rm -f $(MODVERDIR)/*
-+
-+PHONY += $(objtree)/Module.symvers
-+$(objtree)/Module.symvers:
-+ @test -e $(objtree)/Module.symvers || ( \
-+ echo; \
-+ echo " WARNING: Symbol version dump $(objtree)/Module.symvers"; \
-+ echo " is missing; modules will have no dependencies and modversions."; \
-+ echo )
-+
-+module-dirs := $(addprefix _module_,$(KBUILD_EXTMOD))
-+PHONY += $(module-dirs) modules
-+$(module-dirs): crmodverdir $(objtree)/Module.symvers
-+ $(Q)$(MAKE) $(build)=$(patsubst _module_%,%,$@)
-+
-+modules: $(module-dirs)
-+ @echo ' Building modules, stage 2.';
-+ $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost
-+
-+PHONY += modules_install
-+modules_install: _emodinst_ _emodinst_post
-+
-+install-dir := $(if $(INSTALL_MOD_DIR),$(INSTALL_MOD_DIR),extra)
-+PHONY += _emodinst_
-+_emodinst_:
-+ $(Q)mkdir -p $(MODLIB)/$(install-dir)
-+ $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modinst
-+
-+# Run depmod only is we have System.map and depmod is executable
-+quiet_cmd_depmod = DEPMOD $(KERNELRELEASE)
-+ cmd_depmod = if [ -r System.map -a -x $(DEPMOD) ]; then \
-+ $(DEPMOD) -ae -F System.map \
-+ $(if $(strip $(INSTALL_MOD_PATH)), \
-+ -b $(INSTALL_MOD_PATH) -r) \
-+ $(KERNELRELEASE); \
-+ fi
-+
-+PHONY += _emodinst_post
-+_emodinst_post: _emodinst_
-+ $(call cmd,depmod)
-+
-+clean-dirs := $(addprefix _clean_,$(KBUILD_EXTMOD))
-+
-+PHONY += $(clean-dirs) clean
-+$(clean-dirs):
-+ $(Q)$(MAKE) $(clean)=$(patsubst _clean_%,%,$@)
-+
-+clean: rm-dirs := $(MODVERDIR)
-+clean: $(clean-dirs)
-+ $(call cmd,rmdirs)
-+ @find $(KBUILD_EXTMOD) $(RCS_FIND_IGNORE) \
-+ \( -name '*.[oas]' -o -name '*.ko' -o -name '.*.cmd' \
-+ -o -name '.*.d' -o -name '.*.tmp' -o -name '*.mod.c' \) \
-+ -type f -print | xargs rm -f
-+
-+help:
-+ @echo ' Building external modules.'
-+ @echo ' Syntax: make -C path/to/kernel/src M=$$PWD target'
-+ @echo ''
-+ @echo ' modules - default target, build the module(s)'
-+ @echo ' modules_install - install the module'
-+ @echo ' clean - remove generated files in module directory only'
-+ @echo ''
-+
-+# Dummies...
-+PHONY += prepare scripts
-+prepare: ;
-+scripts: ;
-+endif # KBUILD_EXTMOD
-+
-+# Generate tags for editors
-+# ---------------------------------------------------------------------------
-+
-+#We want __srctree to totally vanish out when KBUILD_OUTPUT is not set
-+#(which is the most common case IMHO) to avoid unneeded clutter in the big tags file.
-+#Adding $(srctree) adds about 20M on i386 to the size of the output file!
-+
-+ifeq ($(src),$(obj))
-+__srctree =
-+else
-+__srctree = $(srctree)/
-+endif
-+
-+ifeq ($(ALLSOURCE_ARCHS),)
-+ifeq ($(ARCH),um)
-+ALLINCLUDE_ARCHS := $(ARCH) $(SUBARCH)
-+else
-+ALLINCLUDE_ARCHS := $(ARCH)
-+endif
-+else
-+#Allow user to specify only ALLSOURCE_PATHS on the command line, keeping existing behavour.
-+ALLINCLUDE_ARCHS := $(ALLSOURCE_ARCHS)
-+endif
-+
-+ALLSOURCE_ARCHS := $(ARCH)
-+
-+define find-sources
-+ ( for ARCH in $(ALLSOURCE_ARCHS) ; do \
-+ find $(__srctree)arch/$${ARCH} $(RCS_FIND_IGNORE) \
-+ -name $1 -print; \
-+ done ; \
-+ find $(__srctree)security/selinux/include $(RCS_FIND_IGNORE) \
-+ -name $1 -print; \
-+ find $(__srctree)include $(RCS_FIND_IGNORE) \
-+ \( -name config -o -name 'asm-*' \) -prune \
-+ -o -name $1 -print; \
-+ for ARCH in $(ALLINCLUDE_ARCHS) ; do \
-+ find $(__srctree)include/asm-$${ARCH} $(RCS_FIND_IGNORE) \
-+ -name $1 -print; \
-+ done ; \
-+ find $(__srctree)include/asm-generic $(RCS_FIND_IGNORE) \
-+ -name $1 -print; \
-+ find $(__srctree) $(RCS_FIND_IGNORE) \
-+ \( -name include -o -name arch \) -prune -o \
-+ -name $1 -print; \
-+ )
-+endef
-+
-+define all-sources
-+ $(call find-sources,'*.[chS]')
-+endef
-+define all-kconfigs
-+ $(call find-sources,'Kconfig*')
-+endef
-+define all-defconfigs
-+ $(call find-sources,'defconfig')
-+endef
-+
-+define xtags
-+ if $1 --version 2>&1 | grep -iq exuberant; then \
-+ $(all-sources) | xargs $1 -a \
-+ -I __initdata,__exitdata,__acquires,__releases \
-+ -I EXPORT_SYMBOL,EXPORT_SYMBOL_GPL \
-+ --extra=+f --c-kinds=+px \
-+ --regex-asm='/ENTRY\(([^)]*)\).*/\1/'; \
-+ $(all-kconfigs) | xargs $1 -a \
-+ --langdef=kconfig \
-+ --language-force=kconfig \
-+ --regex-kconfig='/^[[:blank:]]*config[[:blank:]]+([[:alnum:]_]+)/\1/'; \
-+ $(all-defconfigs) | xargs -r $1 -a \
-+ --langdef=dotconfig \
-+ --language-force=dotconfig \
-+ --regex-dotconfig='/^#?[[:blank:]]*(CONFIG_[[:alnum:]_]+)/\1/'; \
-+ elif $1 --version 2>&1 | grep -iq emacs; then \
-+ $(all-sources) | xargs $1 -a; \
-+ $(all-kconfigs) | xargs $1 -a \
-+ --regex='/^[ \t]*config[ \t]+\([a-zA-Z0-9_]+\)/\1/'; \
-+ $(all-defconfigs) | xargs -r $1 -a \
-+ --regex='/^#?[ \t]?\(CONFIG_[a-zA-Z0-9_]+\)/\1/'; \
-+ else \
-+ $(all-sources) | xargs $1 -a; \
-+ fi
-+endef
-+
-+quiet_cmd_cscope-file = FILELST cscope.files
-+ cmd_cscope-file = (echo \-k; echo \-q; $(all-sources)) > cscope.files
-+
-+quiet_cmd_cscope = MAKE cscope.out
-+ cmd_cscope = cscope -b
-+
-+cscope: FORCE
-+ $(call cmd,cscope-file)
-+ $(call cmd,cscope)
-+
-+quiet_cmd_TAGS = MAKE $@
-+define cmd_TAGS
-+ rm -f $@; \
-+ $(call xtags,etags)
-+endef
-+
-+TAGS: FORCE
-+ $(call cmd,TAGS)
-+
-+quiet_cmd_tags = MAKE $@
-+define cmd_tags
-+ rm -f $@; \
-+ $(call xtags,ctags)
-+endef
-+
-+tags: FORCE
-+ $(call cmd,tags)
-+
-+
-+# Scripts to check various things for consistency
-+# ---------------------------------------------------------------------------
-+
-+includecheck:
-+ find * $(RCS_FIND_IGNORE) \
-+ -name '*.[hcS]' -type f -print | sort \
-+ | xargs $(PERL) -w scripts/checkincludes.pl
-+
-+versioncheck:
-+ find * $(RCS_FIND_IGNORE) \
-+ -name '*.[hcS]' -type f -print | sort \
-+ | xargs $(PERL) -w scripts/checkversion.pl
-+
-+namespacecheck:
-+ $(PERL) $(srctree)/scripts/namespace.pl
-+
-+endif #ifeq ($(config-targets),1)
-+endif #ifeq ($(mixed-targets),1)
-+
-+PHONY += checkstack kernelrelease kernelversion
-+
-+# UML needs a little special treatment here. It wants to use the host
-+# toolchain, so needs $(SUBARCH) passed to checkstack.pl. Everyone
-+# else wants $(ARCH), including people doing cross-builds, which means
-+# that $(SUBARCH) doesn't work here.
-+ifeq ($(ARCH), um)
-+CHECKSTACK_ARCH := $(SUBARCH)
-+else
-+CHECKSTACK_ARCH := $(ARCH)
-+endif
-+checkstack:
-+ $(OBJDUMP) -d vmlinux $$(find . -name '*.ko') | \
-+ $(PERL) $(src)/scripts/checkstack.pl $(CHECKSTACK_ARCH)
-+
-+kernelrelease:
-+ $(if $(wildcard include/config/kernel.release), $(Q)echo $(KERNELRELEASE), \
-+ $(error kernelrelease not valid - run 'make prepare' to update it))
-+kernelversion:
-+ @echo $(KERNELVERSION)
-+
-+# Single targets
-+# ---------------------------------------------------------------------------
-+# Single targets are compatible with:
-+# - build whith mixed source and output
-+# - build with separate output dir 'make O=...'
-+# - external modules
-+#
-+# target-dir => where to store outputfile
-+# build-dir => directory in kernel source tree to use
-+
-+ifeq ($(KBUILD_EXTMOD),)
-+ build-dir = $(patsubst %/,%,$(dir $@))
-+ target-dir = $(dir $@)
-+else
-+ zap-slash=$(filter-out .,$(patsubst %/,%,$(dir $@)))
-+ build-dir = $(KBUILD_EXTMOD)$(if $(zap-slash),/$(zap-slash))
-+ target-dir = $(if $(KBUILD_EXTMOD),$(dir $<),$(dir $@))
-+endif
-+
-+%.s: %.c prepare scripts FORCE
-+ $(Q)$(MAKE) $(build)=$(build-dir) $(target-dir)$(notdir $@)
-+%.i: %.c prepare scripts FORCE
-+ $(Q)$(MAKE) $(build)=$(build-dir) $(target-dir)$(notdir $@)
-+%.o: %.c prepare scripts FORCE
-+ $(Q)$(MAKE) $(build)=$(build-dir) $(target-dir)$(notdir $@)
-+%.lst: %.c prepare scripts FORCE
-+ $(Q)$(MAKE) $(build)=$(build-dir) $(target-dir)$(notdir $@)
-+%.s: %.S prepare scripts FORCE
-+ $(Q)$(MAKE) $(build)=$(build-dir) $(target-dir)$(notdir $@)
-+%.o: %.S prepare scripts FORCE
-+ $(Q)$(MAKE) $(build)=$(build-dir) $(target-dir)$(notdir $@)
-+%.symtypes: %.c prepare scripts FORCE
-+ $(Q)$(MAKE) $(build)=$(build-dir) $(target-dir)$(notdir $@)
-+
-+# Modules
-+/ %/: prepare scripts FORCE
-+ $(Q)$(MAKE) KBUILD_MODULES=$(if $(CONFIG_MODULES),1) \
-+ $(build)=$(build-dir)
-+%.ko: prepare scripts FORCE
-+ $(Q)$(MAKE) KBUILD_MODULES=$(if $(CONFIG_MODULES),1) \
-+ $(build)=$(build-dir) $(@:.ko=.o)
-+ $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost
-+
-+# FIXME Should go into a make.lib or something
-+# ===========================================================================
-+
-+quiet_cmd_rmdirs = $(if $(wildcard $(rm-dirs)),CLEAN $(wildcard $(rm-dirs)))
-+ cmd_rmdirs = rm -rf $(rm-dirs)
-+
-+quiet_cmd_rmfiles = $(if $(wildcard $(rm-files)),CLEAN $(wildcard $(rm-files)))
-+ cmd_rmfiles = rm -f $(rm-files)
-+
-+
-+a_flags = -Wp,-MD,$(depfile) $(AFLAGS) $(AFLAGS_KERNEL) \
-+ $(NOSTDINC_FLAGS) $(CPPFLAGS) \
-+ $(modkern_aflags) $(EXTRA_AFLAGS) $(AFLAGS_$(basetarget).o)
-+
-+quiet_cmd_as_o_S = AS $@
-+cmd_as_o_S = $(CC) $(a_flags) -c -o $@ $<
-+
-+# read all saved command lines
-+
-+targets := $(wildcard $(sort $(targets)))
-+cmd_files := $(wildcard .*.cmd $(foreach f,$(targets),$(dir $(f)).$(notdir $(f)).cmd))
-+
-+ifneq ($(cmd_files),)
-+ $(cmd_files): ; # Do not try to update included dependency files
-+ include $(cmd_files)
-+endif
-+
-+# Shorthand for $(Q)$(MAKE) -f scripts/Makefile.clean obj=dir
-+# Usage:
-+# $(Q)$(MAKE) $(clean)=dir
-+clean := -f $(if $(KBUILD_SRC),$(srctree)/)scripts/Makefile.clean obj
-+
-+endif # skip-makefile
-+
-+PHONY += FORCE
-+FORCE:
-+
-+# Cancel implicit rules on top Makefile, `-rR' will apply to sub-makes.
-+Makefile: ;
-+
-+# Declare the contents of the .PHONY variable as phony. We keep that
-+# information in a variable se we can use it in if_changed and friends.
-+.PHONY: $(PHONY)
-diff -Nurb linux-2.6.22-590/arch/arm/Kconfig linux-2.6.22-570/arch/arm/Kconfig
---- linux-2.6.22-590/arch/arm/Kconfig 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/arch/arm/Kconfig 2008-01-23 19:16:03.000000000 -0500
-@@ -1034,8 +1034,6 @@
+ USB ACM DRIVER
+ P: Oliver Neukum
+ M: oliver@neukum.name
+diff -Nurb linux-2.6.22-570/Makefile linux-2.6.22-590/Makefile
+--- linux-2.6.22-570/Makefile 2008-01-29 22:12:20.000000000 -0500
++++ linux-2.6.22-590/Makefile 2008-01-29 22:12:30.000000000 -0500
+@@ -1,7 +1,7 @@
+ VERSION = 2
+ PATCHLEVEL = 6
+ SUBLEVEL = 22
+-EXTRAVERSION = .14-vs2.3.0.29
++EXTRAVERSION = -prep
+ NAME = Holy Dancing Manatees, Batman!
- source "drivers/rtc/Kconfig"
+ # *DOCUMENTATION*
+@@ -496,6 +496,11 @@
+ CFLAGS += -fomit-frame-pointer
+ endif
--source "drivers/dma/Kconfig"
++ifdef CONFIG_UNWIND_INFO
++CFLAGS += -fasynchronous-unwind-tables
++LDFLAGS_vmlinux += --eh-frame-hdr
++endif
++
+ ifdef CONFIG_DEBUG_INFO
+ CFLAGS += -g
+ endif
+diff -Nurb linux-2.6.22-570/Makefile.orig linux-2.6.22-590/Makefile.orig
+--- linux-2.6.22-570/Makefile.orig 2008-01-29 22:12:18.000000000 -0500
++++ linux-2.6.22-590/Makefile.orig 1969-12-31 19:00:00.000000000 -0500
+@@ -1,1493 +0,0 @@
+-VERSION = 2
+-PATCHLEVEL = 6
+-SUBLEVEL = 22
+-EXTRAVERSION = .14
+-NAME = Holy Dancing Manatees, Batman!
+-
+-# *DOCUMENTATION*
+-# To see a list of typical targets execute "make help"
+-# More info can be located in ./README
+-# Comments in this file are targeted only to the developer, do not
+-# expect to learn how to build the kernel reading this file.
+-
+-# Do not:
+-# o use make's built-in rules and variables
+-# (this increases performance and avoid hard-to-debug behavour);
+-# o print "Entering directory ...";
+-MAKEFLAGS += -rR --no-print-directory
+-
+-# We are using a recursive build, so we need to do a little thinking
+-# to get the ordering right.
+-#
+-# Most importantly: sub-Makefiles should only ever modify files in
+-# their own directory. If in some directory we have a dependency on
+-# a file in another dir (which doesn't happen often, but it's often
+-# unavoidable when linking the built-in.o targets which finally
+-# turn into vmlinux), we will call a sub make in that other dir, and
+-# after that we are sure that everything which is in that other dir
+-# is now up to date.
+-#
+-# The only cases where we need to modify files which have global
+-# effects are thus separated out and done before the recursive
+-# descending is started. They are now explicitly listed as the
+-# prepare rule.
+-
+-# To put more focus on warnings, be less verbose as default
+-# Use 'make V=1' to see the full commands
+-
+-ifdef V
+- ifeq ("$(origin V)", "command line")
+- KBUILD_VERBOSE = $(V)
+- endif
+-endif
+-ifndef KBUILD_VERBOSE
+- KBUILD_VERBOSE = 0
+-endif
-
- endmenu
-
- source "fs/Kconfig"
-diff -Nurb linux-2.6.22-590/arch/arm/boot/.gitignore.rej linux-2.6.22-570/arch/arm/boot/.gitignore.rej
---- linux-2.6.22-590/arch/arm/boot/.gitignore.rej 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/arch/arm/boot/.gitignore.rej 1969-12-31 19:00:00.000000000 -0500
-@@ -1,10 +0,0 @@
--***************
--*** 1,2 ****
-- Image
-- zImage
----- 1,5 ----
-- Image
-- zImage
--+ xipImage
--+ bootpImage
--+ uImage
-diff -Nurb linux-2.6.22-590/arch/arm/kernel/Makefile linux-2.6.22-570/arch/arm/kernel/Makefile
---- linux-2.6.22-590/arch/arm/kernel/Makefile 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/arch/arm/kernel/Makefile 2007-07-08 19:32:17.000000000 -0400
-@@ -20,7 +20,6 @@
- obj-$(CONFIG_SMP) += smp.o
- obj-$(CONFIG_KEXEC) += machine_kexec.o relocate_kernel.o
- obj-$(CONFIG_OABI_COMPAT) += sys_oabi-compat.o
--obj-$(CONFIG_KGDB) += kgdb.o kgdb-jmp.o
-
- obj-$(CONFIG_CRUNCH) += crunch.o crunch-bits.o
- AFLAGS_crunch-bits.o := -Wa,-mcpu=ep9312
-diff -Nurb linux-2.6.22-590/arch/arm/kernel/kgdb-jmp.S linux-2.6.22-570/arch/arm/kernel/kgdb-jmp.S
---- linux-2.6.22-590/arch/arm/kernel/kgdb-jmp.S 2008-01-23 19:16:20.000000000 -0500
-+++ linux-2.6.22-570/arch/arm/kernel/kgdb-jmp.S 1969-12-31 19:00:00.000000000 -0500
-@@ -1,32 +0,0 @@
--/*
-- * arch/arm/kernel/kgdb-jmp.S
-- *
-- * Trivial setjmp and longjmp procedures to support bus error recovery
-- * which may occur during kgdb memory read/write operations.
-- *
-- * Author: MontaVista Software, Inc.