linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Linux 2.6.0-test6
@ 2003-09-28  1:27 Linus Torvalds
  2003-09-28  7:03 ` Con Kolivas
                   ` (9 more replies)
  0 siblings, 10 replies; 128+ messages in thread
From: Linus Torvalds @ 2003-09-28  1:27 UTC (permalink / raw)
  To: Kernel Mailing List


Ok, too long between test5 and test6 again, so the patch is pretty big.  
Lots of driver updates and architectures fixed, but also lots of merges
from Andrew Morton. Most notably perhaps Con's scheduler changes that have
been discussed extensively and made it into the -mm tree for testing.

This also finally gets one of the last "must-fix" things for 2.6.0: the 
extended 32-bit dev_t support. Courtesy of Al Viro (with a lot of 
prodding and input over the years from Andries). 

arm, s390, ia64, x86-64, and ppc64 updates. USB, pcmcia and i2c stuff. And 
a fair amount of janitorial.

		Linus

----

Summary of changes from v2.6.0-test5 to v2.6.0-test6
============================================

Adam Belay:
  o [PNPBIOS] compilation fix for pnpbios without proc support
  o [PNP] release card devices on probe failure
  o [PNPBIOS] move detection code into core.c
  o [PNP] remove DMA 0 restrictions
  o janitor: remove unneeded includes (isapnp)
  o [ISAPNP] remove unused isapnp_allow_dma0 modparam
  o [PNPBIOS] return proper error codes on init failure
  o [PNPBIOS] move some more functions to local include file

Adam Radford:
  o 3ware driver update

Adrian Bunk:
  o ATM Ambassador no longer BROKEN_ON_SMP
  o input: Fix Kconfig KEYBOARD_ATKBD when SERIO is modular
  o fix sbni.c compile with gcc 3.3
  o USB: fix USB_MOUSE help text
  o select MII
  o select ZLIB_{IN,DE}FLATE

Alan Stern:
  o USB: Use num_altsetting in usbnet and usbtest
  o USB: Changes to core/config.c (1 - 9)
  o USB: improve debugging logging during suspend and resume
  o (as84) Small fixup for SCSI proc code

Albert Cahalan:
  o fix for hidden-task problem
  o fix CONFIG_SECURE trouble in thread-aware procfs
  o use CLONE_KERNEL
  o shared signals require shared VM

Alexander Viro:
  o ps2esdi broken
  o prepare for 32-bit dev_t: reiserfs/procfs.c
  o prepare for 32-bit dev_t: drm debugging printks
  o prepare for 32-bit dev_t: XFS
  o prepare for 32-bit dev_t: tty usage
  o prepare for 32-bit dev_t: NFS
  o prepare for 32-bit dev_t: JFS
  o prepare for 32-bit dev_t: jffs2 cleanups
  o prepare for 32-bit dev_t: md.c cleanups
  o prepare for 32-bit dev_t: dm-ioctl-*.c
  o prepare for 32-bit dev_t: misc cleanups
  o prepare for 32-bit dev_t: mknod()/ustat()
  o prepare for 32-bit dev_t: loop.c
  o prepare for 32-bit dev_t: CODA
  o prepare for 32-bit dev_t: stat()
  o 32-bit dev_t: internal use
  o 32-bit dev_t: switch-over
  o 32-bit dev_t fixups
  o 32-bit dev_t fallout: mips/kernel/sysirix.c
  o 32-bit dev_t: md fallout
  o Avoid /proc/{ioports,iomem} truncation
  o ppc64 typo fix (kudos to Anton)

Alexey Dobriyan:
  o USB: Remove setting TASK_RUNNING after schedule_timeout in
    /drivers/usb/

Amir Noam:
  o [bonding 2.6] fix 802.3ad long fail over with high UDP Tx stress
  o [bonding 2.6] fix load balance problem with high UDP Tx stress
  o [bonding 2.6] fix ARP monitoring bug
  o [bonding 2.6] fix kernel panic when optional feature used
  o [bonding 2.6] fix change active command
  o [bonding 2.6] fix OOPS in bonding driver, when removing primary
  o [bonding 2.6] embed stats struct inside bonding private struct
  o [bonding 2.6] fix error handling in init code
  o [bonding 2.6] make each bond device use its own /proc entry
  o [bonding 2.6] misc fixes: missing include, typos, comments
  o [bonding 2.6] consolidate change_active operations
  o [bonding 2.6] fix assign_current_slave
  o [bonding 2.6] Decouple promiscuous handling from multicast mode
    setting
  o [bonding 2.6] Add support for changing HW address and MTU
  o [bonding 2.6] Add support for changing HW address in ALB/TLB modes
  o [bonding 2.6] Consolidate /proc code, add CHANGENAME handler
  o [bonding 2.6] Enhance netdev notification handling
  o [bonding 2.6] Add missing free_netdev()
  o [bonding 2.6] Fix ipx_hdr compile error
  o [bonding] Convert /proc to seq_file

Andi Kleen:
  o x86-64 merge
  o Minor K8 fix for oprofile
  o Pad statvfs in compat layer
  o Generalize 32bit emulation support in MPT fusion
  o Another x86-64 merge - make it boot again
  o Another small x86-64 merge

Andrej Borsenkow:
  o I2C: sysfs sensor nameing inconsistency

Andrew Morton:
  o [PCMCIA] RL5C4XX_16BIT_MEM_0 was wrong
  o s/spin_lock_irqrestore/spin_unlock_irqrestore
  o calibrate_tsc() fix and consolidation
  o Initialise devfs_name in various block drivers
  o monolitic_clock, timer_{tsc,hpet} and CPUFREQ
  o dac960 devfs_name initialisation fix
  o compiler warning fixes for DAC960 on alpha
  o Move ikconfig to /proc/config.gz
  o reiserfs direct-IO support
  o Fix imm.c again
  o make selinux enable param config option, enabled by
  o sound: remove duplicate includes
  o remove duplicate includes in kernel/
  o Handle NR_CPUS overflow
  o ppp devfs oops fix
  o d_delete-d_lookup race fix
  o ia32 idle using PNI monitor/mwait
  o remap file pages MAP_NONBLOCK fix
  o install_page pte use-after-unmap fix
  o really use english date in version string
  o tidy up lib/inflate.c error messages
  o ext3: remove debug code
  o mwave locking fixes
  o fix Summit srat.h includes
  o Reduce random driver lock contention
  o sys_fadvise needs asmlinkage
  o CPU scheduler CAN_MIGRATE fix
  o [NET]: Remove spurious TASK_RUNNING setting after
    schedule_timeout()
  o Fix imm.c again
  o e1000 bug
  o procfs build fix for older gcc
  o ECC support
  o real-time enhanced page allocator and throttling
  o Fix setpgid and threads
  o reiserfs: large file 32/64-bit truncation fix
  o Overflow check for i386 assign_irq_vector
  o mtrr warning fix w/o proc_fs
  o NLS: Remove the nls modules for only alias
  o NLS: remove emacs metadata
  o scheduler infrastructure
  o sched_clock() for ppc, ppc64, x86_64 and sparc64
  o CPU scheduler balancing fix
  o CPU scheduler interactivity changes
  o might_sleep diagnostics
  o Move slab objects to the end of the real allocation
  o Remove Documentation/smp.tex
  o AGP warning fix
  o mwave char/Kconfig fix
  o any_online_cpu fix
  o allow x86 NUMA architecture detection to fail
  o misc fixes
  o reiserfs: add checks from 2.4 into 2.5
  o remove duplicate SOUND_RME96XX option
  o istallion: use schedule_work
  o file locking memory leak
  o fix incorrect argv[0] for init
  o ens1370 PCI driver naming fix
  o Summit sub-arch: Make logical IDs independent of BIOS numbering
    scheme
  o wanXL serial card driver
  o floppy cleanup timers/resources on unload
  o remove /proc/config_build_info
  o access_ok is likely
  o Update Documentation/block/biodoc.txt
  o Fix typo in scripts/postmod.c
  o Export new char dev functions
  o hangcheck compile fix
  o NCR5380 timeout fix
  o Incorrect value for SIGRTMAX
  o x445: setup_ioapic_ids_from_mpc fix
  o deadline insert_here fix
  o bio_dirty_fn() page leak fix
  o Speed up direct-io hugetlbpage handling
  o Handle init_new_context failures
  o Fix sem_lock deadlock
  o zoran driver documentation fix
  o AS oops fix
  o kill superflous kdev_t.h inclusions
  o move some more initializations out of drivers/char/mem.c
  o rio.c: remove TWO_ZERO
  o mlock error handling fix
  o fix cciss memory leaks
  o ia64 sched_clock() implementation
  o misc fixes
  o smbfs NLS fix
  o slab: hexdump structures when things go wrong
  o Try harder in IRQ context before falling back to ksoftirqd
  o mark devfs obsolete
  o kill some leftovers from the big sysrq syncing rewrite
  o add -Wdeclaration-after-statement
  o disallow utime{s}() on immutable or append-only files
  o switch remaining serial drivers to initcalls
  o misc fixes
  o Hugetlb FS quota accounting problem
  o make CONFIG_HUGETLB_PAGE mirror CONFIG_HUGETLBFS
  o setuid clearing fix
  o remove CONFIG_SERIAL_21285_OLD
  o DAC960: remove redundant (and uninitialized)
  o wanxl compile and warning fixes
  o use "normalized" syntax for lgdt/lidt
  o asm/softirq.h is dead
  o SELinux leak fixes
  o do_brk() bounds checking
  o fix MD "bio too big" errors

Andries E. Brouwer:
  o compilation fix ufs
  o sparse fix sysctl, eventpoll, cpufreq, xattr, kcore,
    ext2_readlink, reboot, proc/misc, fat/file.c, kmsg,
    proc/generic
  o another keyboard problem solved
  o fix keycode for rctrl in scancode set 3
  o input: Fix Set3 keycode for right control in atkbd.c

Andy Grover:
  o ACPI maintainer change

Angelo Dell'Aera:
  o saa9730 (minor revision)

Anton Altaparmakov:
  o Adrian Bunk: Postfix an NTFS constant that is too big for an int
    with ULL
  o NTFS: Update documentation for Linux kernel 2.6

Anton Blanchard:
  o ppc64: make install target from Dave Hansen
  o ppc64: Remove find_pci_device_OFnode prototype, from Nathan Lynch
  o ppc64: iseries soft disable and do_page_fault fixes from Ben
    Herrenschmidt
  o ppc64: xics fix for I/O slot deconfigure, from Linda Xie
  o ppc64: fixes for pci_name() changes
  o ppc64: Fix NUMA compile after cpu bitmasks merge
  o ppc64: remove broken xmon h option
  o ppc64: semaphore fixes based on report by ever watchful Olaf Hering
  o ppc64: remove interrupt stacks which broke when the thread info
    stuff went in
  o ppc64: defconfig update
  o ppc64: remove some unused entries in the paca
  o ppc64: make install fixes from Dave Hansen
  o ppc64: fix gcc 3.3 compile
  o ppc64: Fix 3rd and 4th serial port from Olof Johansson
  o ppc64: add missing IPC_64 mask, from sparc64 and add some compat
    types
  o ppc64: Fix some error return paths in sys_ipc
  o ppc64: add might_sleep() to uaccess functions
  o ppc64: register_ioctl32_conversion defined twice, fix from Olaf
    Hering
  o ppc64: rtas rtc fixes from Todd Inglett
  o ppc64: export node_data and numa_memory_lookup_table
  o ppc64: defconfig changes
  o ppc64: discard exit sections
  o ppc64: fix bogus NR_CPUS*2 struct in xics.c
  o ppc64: Update unhandled irq code to match x86
  o ppc64: start using kallsyms now its compiled in by default
  o ppc64: convert xmon to use kallsyms now its compiled in by default
  o ppc64: ppc64 Hugepage support from David Gibson
  o ppc64: forgot to add the guts of hugetlb support
  o ppc64: hugetlb fixes for LPAR and numa hugetlb support
  o ppc64: catch bad ioctl size at compile time, from x86
  o ppc64: Give us a generic local.h until we have atomic64
  o fix oops in hvc_console
  o Fix initramfs permissions on directories and special files
  o quieten initramfs and fix /dev permissions
  o serialize bus scanning

Armin Schindler:
  o eicon ISDN driver: memory attach
  o eicon ISDN driver: capi code fix
  o eicon ISDN driver: debug
  o eicon ISDN driver: list handling
  o eicon ISDN driver: endianess
  o eicon ISDN driver: Kernelconfig
  o eicon ISDN driver: C comments
  o eicon ISDN driver: update
  o Eicon ISDN driver: removed __devinitdata from pci_device_id
  o Eicon ISDN driver: remove old devfs_handle

Arnaldo Carvalho de Melo:
  o [NETFILTER]: Fix typo in recent ip_input.c changes
  o LLC: introduce llc_type_handlers
  o LLC: move llc_decode_pdu_type to llc_mac
  o LLC: move llc_conn_handler and llc_sap_handler out of llc_mac
  o LLC: remove another silly net 4.0 banner
  o LLC: move the connection related functions to llc_conn
  o LLC: move sap functions to llc_sap
  o LLC: move the sockets release function outside of llc_sap_close
  o LLC: move llc_build_and_send_ui_pkt to llc_sap
  o LLC: move llc_lookup_dgram to llc_sap
  o LLC: move the pdu routines needed by the upcoming llc_core to
    llc_pdu.h
  o LLC: implement llc_add_pack/llc_remove_pack
  o LLC: split llc into llc_core and llc2 modules
  o LLC: add some unlikely wrappings in llc_mac
  o LLC: create llc_output and move lan_hdrs_init to it
  o LLC: create a register interface for llc_station_rcv
  o LLC: rename llc_mac.c to llc_input.c, net/llc_mac.h to net/llc.h
  o LLC: trim down llc_core to the very basic support needed by IPX
    et all
  o LLC: rename llc_main.[ch] to llc_station.[ch]
  o LLC: reorganize llc_station.c to kill useless static prototypes
  o LLC: consolidate the LLC station component into llc_station.c
  o LLC: llc_station.h is not useful anymore, kill it
  o LLC: use list_for_each_entry in llc_sap_find
  o LLC: remove unneeded EXPORT_SYMBOLs from llc_sap

Arun Sharma:
  o ia64: MINSIGSTKSZ on ia32

Bart De Schuymer:
  o [NETFILTER]: Fix parisc64 alignment problems in ipt_physdev.c

Benjamin Herrenschmidt:
  o IDE: Fix request handling with ide-default & ATAPI
  o IDE: Fix Power Management request race on resume
  o dmasound update from Christoph Hellwig
  o Support for POWER4 & GPUL (G5) CPUs
  o Fix cputable.c build (missing commas)

Bernardo Innocenti:
  o GCC 3.3.x/3.4 compatiblity fix in include/linux/init.h

Bjorn Helgaas:
  o ia64: clean up acpi_boot_init()
  o ia64: trivial sba_iommu patch
  o ia64: bail out of sba_init() if no hardware found

Brian Gerst:
  o lp.c module alias
  o select CRC32

Chas Williams:
  o [ATM]: Remove unnecessary GFP_ATOMIC allocation
  o [ATM]: Fix build failure with ATM_BR2684_IPFILTER enabled
  o [ATM]: seq_file for /proc/net/atm (devices)
  o [ATM]: exporting llc_oui[] isn't worth it
  o [ATM]: Fix race between modifying entry->vccs and
    clip_start_xmit()
  o [ATM]: Correct way to prevent module unload
  o [ATM]: [firestream] Allow module refcounting
  o [ATM]: [idt77252] Get rid of MOD_INC/MOD_DEC
  o [ATM]: [lanai] Get rid of MOD_INC/MOD_DEC
  o [ATM]: [uPD98402] Convert to new-style module
  o [ATM]: [uPD98402] Exported symbols should not be marked __init
  o [ATM]: If CLIP is not enabled, try_atm_clp_ops() should always fail
  o [ATM]: [ioctl][1/8] Move vcc_ioctl() to ioctl.c
  o [ATM]: [ioctl][2/8] Add registration functions
  o [ATM]: [ioctl][3/8] Use new code for pppoatm and br2684
  o [ATM]: [ioctl][4/8] Use new code for mpoa
  o [ATM]: [ioctl][5/8] Change ncc clip info handling
  o [ATM]: [ioctl][6/8] Move clip seq_file ops to clip.c
  o [ATM]: [ioctl][7/8] Use new code for clip
  o [ATM]: [ioctl][8/8] Use new code for atmtcp
  o [ATM]: Move lan seq_file ops to lec.c
  o [ATM]: Use dev_get_by_name() instea of atm_lane_ops->get_lec()
  o [ATM]: Use new ioctl code for lane

Chris Wright:
  o update credits
  o Add LSM maintainer entry
  o LSM comment fixup
  o root_plug fixup
  o [IPV4]: Use cpu_relax() in ipconfig.c
  o [netdrvr] use cpu_relax() in busy loop, or mdelay instead of busy loop
  o Memory leak in ixj_pcmcia driver
  o USB: Memory Leaks on Error Paths of usb-midi

Christoph Hellwig:
  o [PCMCIA] kill flush_stale_links
  o [PCMCIA] kill dead DEV_STALE_* codepathes in non-networking drivers
  o [NET]: Kill a dead extern in net/core/dev.c
  o change sdev.access_count to an atomic_t
  o kill highmem_io leftover
  o kill use_blk_tcq template flag
  o kill scsi_cmnd.flags
  o bring lost 2.5 changes to qla1280 back
  o tiny zalon cleanups
  o helper for device list traversal
  o kill last users of the ScsiLun typedef
  o small lasi700 update
  o move some constants around
  o add back the missing ->slave_destroy call
  o handle failure when starting the eh thread
  o switch command completion queue to per-cpu data
  o [NET]: Consolidate ax25/isdn/bluetooth Kconfig inclusion
  o fix qla1280 compiles
  o ia64: kill SN kdba_io.c
  o ia64: kill sn2 inventory stubs
  o ia64: kill dead SN code from ml_iograph.c
  o ia64: kill snia_pciio_*
  o ia64: simplify and speedup SN2 dma mapping
  o ia64: sn_ML_intr.c is a freakin mess
  o ia64: simplify SN2 interrupt allocation
  o ia64: remove CONFIG_PCI ifdefs in SN2 code

Daniel A. Nobuto:
  o USB: make pdfdocs problem

Daniel Drake:
  o USB: Debug code fixes for vicam
  o USB: Debug code fixes for usblp
  o USB: Debug code fixes for dabusb

Daniele Bellucci:
  o USB: Minor cleanups in usb_serial_probe

Dave Jones:
  o [AGPGART] Mention Intel 875 support in Kconfig
  o [AGPGART] Fix ATI GART for IGP9100/R300 From the folks at ATI. Some
    chips hang with this flush.
  o [AGPGART] Remove unreferenced extern
  o [CPUFREQ] Merge speedstep-smi driver
  o [CPUFREQ] remove $Id$ tags, update filenames
  o [CPUFREQ] add cpufreq_update_policy()
  o [IPV6]: Fix non-CONFIG_PROC_FS build
  o [CPUFREQ] CodingStyle fixes for speedstep-smi
  o [CPUFREQ] Don't print out speedstep stuff on non-Intel CPUs
  o [CPUFREQ] use PFX macro in common printk's
  o [CPUFREQ] Fix up debug printk formatting string in speedstep-smi
  o [AGPGART] Fix silly logic bug in modular AMD64 GART driver
  o [AGPGART] Missing prefixes in printk's
  o [AGPGART] Fix missing/bogus includes
  o [CPUFREQ] Add missing config.h includes
  o [AGPGART] Add HP AGP 8x bridge and fix ACPI claim The following
    patch to the HP ZX1 GART driver
  o [AGPGART] Fix module alias
  o [CPUFREQ] Read MSRs before trying to use them in powernow-k7 Very
    silly bug spotted by Ducrot Bruno
  o [CPUFREQ] We need to set SGTC when we change powernow-k7 voltage
  o [CPUFREQ] Work around buggy powernow-k7 BIOSes with low settling
    times
  o [CPUFREQ] Powernow-k7 latency timer needs to be in values of 10ns
  o [CPUFREQ] Explicitly disable scaling we don't need in powernow-k7
    The VIDC/FIDC controls could have been left at 1 from a previous
    call to

Dave Kleikamp:
  o JFS: Fix rampant data corruption

David Brownell:
  o USB: usb/gadget/Kconfig, use right PXA2xx symbols
  o USB: psdocs fails for usbgadget
  o USB: usb "ether" net gadget
  o USB: usb gadgetfs updates
  o USB: usb_set_configuration() rework (v2)

David Howells:
  o RxRPC update
  o AFS update

David Mosberger:
  o ia64: Drop unnecessary fadvise64_64() bloat (it isn't needed on
    64-bit platforms).
  o ia64: Document the typo that made it into the definition of
    MINSTKSZ (last two numbers got transposed).  Thanks to Arun Sharma
    for finding this.  New glibc's will have the value corrected, but
    we leave the kernel at the old (bogus) value to retain backwards-
    compatibility (and while a strange value, the old value works just
    fine).
  o ia64: Finnish adding ECC support.  Based on patch by Suresh Siddah
  o ia64: Fix asm-ia64/acpi.h typo & name-collision
  o ia64: Direct sys_fadvise64() to sys_fadvise64_64()
  o ia64: Fix things so that they compile with the latest GCC 3.4,
    which optimize away static variables with no compiler-visible use.
  o ia64: Drop unnecessary version check in sba_iommu.c
  o ia64: Re-enable /proc/sal support.  Bug reported by Stephane
    Eranian, patch by Jesse Barnes.
  o ia64: In <asm-ia64/param.h>, do not include <linux/config.h>
    outside the #ifdef __KERNEL__ bracket.  Doing so pollutes the user-
    level namespace.  Bug report & proposed fix by GOTO Masanori.
  o ia64: Control /proc/bus/mckinley/zx1 via separate SBA_PROC_FS macro
    and turn SBA_PROC_FS off by default (it's too much of a scalability
    bottleneck).
  o ia64: Based on patch by Jess Barnes: split up memory-initialization
    from kernel/setup.c into two separate files: mm/{dis,contig}.c to
    handle contiguous vs. discontiguous memory layouts.
  o ia64: Improve comment for reserve_memory()
  o ia64: Mark access_ok() as likely to succeed (as is done in x86
    tree)
  o ia64: Patch by Christoph Hellwig: Kill two SN headers never
    references in the current tree.
  o ia64: Patch by Christoph Hellwig: None of the exported symbols is
    referenced by a module, even more the file doesn't compile when
    CONFIG_IA64_SGI_SN_DEBUG is set.
  o ia64: Patch by Christoph Hellwig: SN2 stopped abusing devfs in 2.5,
    clean up the leftovers.
  o ia64: Patch by Christoph Hellwig: kill .hcl entry in SN hwgfs

David S. Miller:
  o [SPARC64]: Update defconfig
  o [SPARC64]: Make sure cpu_data[0].udelay_val gets setup on non-SMP
    (found by bde@nwlink.com)
  o [UDP]: In udp_{v6_}flush_pending_frames, reset up->len too
  o [NET]: Increase ethernet tx_queue_len to 1000
  o [IPV4]: Fix skb leak in igmp.c
  o [LLC]: llc_core.c needs linux/init.h
  o [I2C]: Several drivers forget to include asm/io.h
  o [NET]: Unlink qdiscs in qdisc_destroy even when CONFIG_NET_SCHED is
    not enabled
  o [SPARC64]: Update defconfig
  o [SPARC64]: Handle WDISP19 relocations in modules
  o [ATM]: atmtcp.c needs linux/init.h
  o [ATM]: Add struct net_bridge decl to net/atm/common.c
  o [ATM]: Fix atm_mpoa_disp_qos() second arg to be ssize_t
  o [IPV4]: Use correct ptrdiff_t printf format in ipmr.c
  o [IPVS]: Print out __u64 properly in ip_vs_ctl.c

David T. Hollis:
  o USB: ethtool_ops and ax8817x fixes for usbnet
  o USB: Remove ax8817x driver

David Woodhouse:
  o [BLUETOOTH]: Fix bug in set_sk_owner() changes
  o [BLUETOOTH]: Add missing owner to bnep_sock_family_ops

Dean Roehrich:
  o [XFS] Change dm_send_namesp_event to take vnode ptrs rather than
    bhv ptrs

Dennis Jørgensen:
  o [IPV4]: Fix wrong IP address in icmp.c error message

Dmitry Torokhov:
  o serio.c
  o input: Fix multibutton handling in Synaptics.c (nExtBtn > 8 case)
  o input: Synaptics code cleanups

Duncan Sands:
  o USB speedtouch: use multiple urbs by default
  o USB: New email address for duncan
  o USB speedtouch: neater sanity check
  o USB speedtouch: bump the version number

Eric Sandeen:
  o [XFS] remove doubly-included header files
  o [XFS] Re-work xfs stats macros to support per-cpu data
  o [XFS] Update sysctls - use ints, not ulongs, and show pagebuf
    values in jiffies like everybody else

Erlend Aasland:
  o [CRYPTO]: Add alg. type to /proc/crypto output

Eyal Lebedinsky:
  o wl3501 with old compiler

Felipe Damasio:
  o slip.c: current state cleanup
  o [NET]: Kill unneded version.h in net/sched
  o Unneeded memory barrier in net/irda code
  o Memory leak in scsi_debug found by checker
  o Memory leak in NCR_Q720 found by checker

François Romieu:
  o (1/4) sdla - move out of Space.c

Geert Uytterhoeven:
  o in2000 warning

Greg Kroah-Hartman:
  o PCI hotplug: fix up a bunch of copyrights that were incorrectly
    declared
  o I2C: added new id for Radeon driver
  o PCI: remove compiler warning from previous new_id patch
  o PCI: fix up some pci drivers that had marked their probe functions
    with __init
  o I2C: remove some usages of i2c_adapter.id as they are not used
  o I2C: add the i2c-sis5595 i2c bus driver
  o I2C: add the i2c-sis630 i2c bus driver
  o I2C: add the i2c-via i2c bus driver
  o I2C: clean up the i2c bus Kconfig menu and help texts
  o I2C: turn off debugging on the new sis i2c bus drivers
  o USB: fix oops when trying to suspend and resume
  o USB: fix oops in ipaq driver
  o USB: fix up missing </para> in usb documentation
  o USB: make sure we never reference a usbserial port after it has
    been unregistered
  o USB: unusual device fixup for the Y-E floppy drive
  o I2C: add the i2c-i810 i2c bus driver
  o I2C: add the i2c-savage4 i2c bus driver
  o I2C: add the i2c-voodoo3 i2c bus driver
  o I2C: clean up the i2c chips Kconfig logic and help information
  o I2C: clean up the drivers/i2c/Kconfig file
  o I2C: move i2c-prosavage.c driver to drivers/i2c/busses where it
    belongs
  o I2C: clean up i2c-prosavage.c driver
  o I2C: fix up dependancies in the i2c/busses/Kconfig file
  o I2C: move the i2c-philips-par driver to drivers/i2c/busses
  o I2C: clean up i2c-philips-par.c driver a bit
  o I2C: move i2c-elv.c driver to drivers/i2c/busses
  o I2C: clean up the i2c-elv.c driver a bit
  o I2C: move i2c-elektor.c driver to drivers/i2c/busses/
  o I2C: move i2c-velleman driver to drivers/i2c/busses
  o I2C: move the scx200* drivers to drivers/i2c/busses
  o I2C: move the remaining i2c bus drivers to drivers/i2c/busses
  o I2C: remove check_region usage and warning from i2c-sensor
  o I2C: remove I2C_VERSION and I2C_DATE as they make no sense in the
    kernel tree
  o I2C: remove the isa address check alltogether
  o I2C: move the i2c algorithm drivers to drivers/i2c/algos
  o I2C: add eeprom i2c chip driver
  o I2C: remove unneeded #defines in the eeprom chip driver
  o USB: remove misleading FIXME comment added by previous patch
  o USB: i was wrong, clean up some extra refcounts that are no longer
    needed

Guillaume Morin:
  o fix cpu_test_and_set() on UP

Harald Welte:
  o [NETFILTER]: Clear nf_debug in ipsec tunnel case
  o [NETFILTER]: Use u16 for port numbers

Henning Meier-Geinitz:
  o USB scanner driver: use static declarations
  o USB scanner driver: report back return codes
  o USB scanner driver: balancing usb_register_dev/usb_deregister_dev
  o USB scanner driver: new device ids
  o USB scanner driver: added USB_CLASS_CDC_DATA

Herbert Xu:
  o [XFRM]: Fix ALLOC_SPI for IPCOMP

Hideaki Yoshifuji:
  o [NET]: Various /proc/net/* files may drop some data
  o [NET]: /proc/net/if_inet6 may drop some data
  o [NET]: Clean up /proc/net/{anycast6/igmp6}
  o [NET]: Use proc_net_fops_create() and proc_net_remove() in net/core
  o [NET]: Use proc_net_fops_create() and proc_net_remove() in net/ipv4
  o [NET]: Use proc_net_fops_create() and proc_net_remove() in net/ipv6
  o [IPV4]: Convert /proc/net/pnp to seq_file
  o [NET]: Use proc_net_fops_create() for /proc/net/wireless

Hirofumi Ogawa:
  o DEVICE_NAME_SIZE/_HALF removal (I2C stuff)
  o DEVICE_NAME_SIZE/_HALF removal (I2C related, but v4l stuff)
  o DEVICE_NAME_SIZE/_HALF removal (I2C related, but fb stuff)
  o [NETFILTER]: Fix typoe in ip_nat_tftp.c

Holger Freyther:
  o [ARM PATCH] 1653/1: Simpad Flash Partition resubmit
  o [ARM PATCH] 1654/1: Simpad PCMCIA resubmit
  o [ARM PATCH] 1656/1: Simpad board update to make it work

Holger Schurig:
  o [ARM] Add sched_clock()

Ian Abbott:
  o USB: ftdi_sio - new vid/pid for OCT US101 USB to RS-232 converter

Jamal Hadi Salim:
  o [NET]: Make pfifo_fast actually report statistics

James Bottomley:
  o .del-sym53c8xx.c~180cda83f20a4355
  o fix smc-mca cleanup breakage
  o Remove killed SCSI_IOCTL_TAGGED_{ENABLE|DISABLE} from
    compat_ioctl.h
  o scsi_mid_low_api.txt update

Jan Harkes:
  o Coda updates

Jaroslav Kysela:
  o ALSA CVS updates
    - clean up the usage of the size variable and removes size1.
    - define AD198x bits.
    - add descriptions for whole-frag and no-silence commands.
    - use dxs_support=3 (48k fixed) as default, since there are so many problems
      with dxs_support=0.
    - add the support for stereo mute switches on AD198x.
    - initialize tumbler/snapper audio via gpio before i2c initialization.
    - add check of DXS supports (so far, empty).
    - add detection of revision of ALC650 chip
    - get_page() fix
    - fix the SPDIF bit on aureon boards.
    - set 48k only for the sample rate of SPDIF on nForce.
    - kill of not-required version.h inclusion
    - Remove duplicated include
    - fix buffer overlap on FX8010 PCM.
    - Fix hwdep hotplug problem
    - Use try_module_get() and module_put() to block the toplevel module
    - Fix returned error code in the release() callback
    etc

Javier Achirica:
  o [wireless airo] fix PCI probe
  o [wireless airo] Fix MIC support with CryptoAPI

Jeff Garzik:
  o Fix netdev close
  o [sound/oss i810_audio] sync with 2.4
  o [docbook] fix embedded filename in kernel-api docbook doc
  o [docbook] fix docbook build, by closing several unclosed tags
  o [BK] "bk ignore" a ton of docbook-generated output
  o [BK] "bk ignore" generated files that appeared during "make
    allyesconfig"

Jens Axboe:
  o Fix blk_stop_queue bug
  o get rid of warning in gscd
  o blk API update (and bug fix) to CDU535 cdrom driver
  o ide-cd capacity "bug"
  o shared block queue tag map
  o io scheduler barrier fix
  o ide-cd cgc command bug
  o cdrom memory leaks

Jes Sorensen:
  o ia64: remove unused sn2 header files
  o ia64: small sn2 cleanup
  o ia64: sn2 header file cleanup
  o ia64: include/asm-ia64/sn/router.h cleanup
  o ia64: fix for include/asm-ia64/acpi.h

Jesse Barnes:
  o ia64: misc. sn2 updates
  o ia64: fix current usage in sn2 code
  o ia64: cpumask_t fixes
  o ia64: update Kconfig comment for NR_CPUS
  o ia64: turn off SLIT debugging
  o ia64: protect PAL mapping printk with EFI_DEBUG

Jochen Friedrich:
  o [tokenring] fix breakage in proteon, skisa

Joe Perches:
  o Add SEQ_START_TOKEN #define to seq_file.h
  o Use SEQ_START_TOKEN in drivers/net/* [1/3]
  o Use SEQ_START_TOKEN in include/net/* [2/3]
  o Use SEQ_START_TOKEN in include/net/* [3/3]
  o Fix SEQ_START_TOKEN typo
  o [NET]: Add and use PKT_CAN_SHARE_SKB instead of (void *) 1

John Levon:
  o [NET]: SEQ_START_TOKEN for af_netlink.c

Jun Komuro:
  o [netdrvr] build fixes
  o [netdrvr smc91c92_cs] select proper bank for MII registers

Keith M. Wesolowski:
  o [SPARC32]: Ignore btfixups in .text.exit

Kevin Corry:
  o dm: Use new format_dev_t macro
  o dm: Drop extra table ref-count
  o dm: Move retrieve_status function
  o dm: Return table status for dev_wait
  o dm: Message fix in dm-linear
  o dm: Support arbitrary number of target params

Kevin P. Fleming:
  o [NET]: Make netdevice.h more userspace friendly

Krishna Kumar:
  o [IPV6]: Export devconf device settings via netlink

Kumar Gala:
  o Added "user64" versions of the user access functions that allow
    modification of 64-bit data.
  o PPC32; Added "user64" versions of the user access functions that
    allow modification of 64-bit data.

Leonard Norrgard:
  o Kconfig

Linus Torvalds:
  o Fix CONFIG_PCMCIA_WL3501 with older compilers
  o Make rxrpc use SEQ_START_TOKEN
  o From Stephen Hemminger: we were trying to cast an "unsigned short"
    to a pointer. That was a typo.
  o Fix ray_cs for new interrupt handling
  o Avoid type warning for bit operation in atkbd.c
  o Don't ask about SERIO selection - let Kconfig select it
    automatically as needed.
  o Disable forced keyrelease in atkbd driver. It breaks modifier keys
  o Remove incorrect and unnecessary definition of "errno" that causes
    link-time duplicate symbol errors.
  o sd.c: be more cautious in asking for mode page 8 data,
    sanity-checking the information more carefully. 
  o DRI CVS merge: add DRM(calloc)() function, and remove unnecessary
    TLB flush after vmap.
  o DRI CVS merge: whitespace cleanups for i810_dma.c
  o DRI CVS merge: r128 driver private function cleanup
  o DRI CVS merge: radeon driver update
  o DRI CVS merge: SiS driver updates from Eric Anholt
  o DRI CVS merge: portability defines
  o Avoid warning about non-newline whitespace at end of file
  o Include proper <linux/device.h> for chrdev alias
  o Fix up DRI CVS merge of sis driver with CONFIG_FB_SIS
  o Avoid compiler warning by using the proper types in "min()"
  o Mark PM_DISK_PARTITION as depending on PM_DISK, so as to avoid an
    annoying nonsense configuration question.
  o Revert NDEBUG move in NCR5380 - g_NCR5380 includes the file (ugh)
    and wants 'phases'

Luiz Capitulino:
  o input: Fix a warning in input.c when CONFIG_PROC_FS is not set
  o input: Remove a not necessary #ifdef CONFIG_PROC_FS/#endif in
    input.c

Maksim Krasnyanskiy:
  o Bluetooth: RFCOMM must send MSC when DLC was opened by SABM
  o [Bluetooth] Fix RFCOMM C/R and Direction bits handling
  o [Bluetooth] Add support for SO_LINGER to L2CAP, RFCOMM and SCO
    sockets
  o [Bluetooth] L2CAP qualification spec mandates sending additional
    config request if we receive config response with unacceptable
    parameters error code. 
  o [Bluetooth] Convert BNEP protocol to dynamic allocation of network
    devices

Maneesh Soni:
  o [NET]: Remove attribute group when unregistering netdev from sysfs

Marc Zyngier:
  o depca update

Marcel Holtmann:
  o [Bluetooth] Send correct RPN response for accepted values
  o [Bluetooth] Set EA bit for V.24 signals parameter
  o [Bluetooth] Handle bit rate in remote port negotiation
  o [Bluetooth] Quirk for devices with no ISOC endpoints
  o [Bluetooth] Make READ_TRANSMIT_POWER_LEVEL available for normal
    users
  o [Bluetooth] Support for inquiry with unlimited responses
  o [Bluetooth] Handle command complete event for inquiry cancel
  o [Bluetooth] Update the maintainer entries for the Bluetooth
    subsystem
  o [Bluetooth] Add tiocmget() and tiocmset() routines to RFCOMM TTY
  o [Bluetooth] Add support for FCon and FCoff flow control commands

Marcelo Tosatti:
  o WM9712 suspend/resume nopop

Mark Studebaker:
  o I2C: i2c-isa functionality

Martin Schlemmer:
  o I2C: Fix conversion from milli volts in store_in_reg() for
    w83781d.c

Martin Schwidefsky:
  o s390: arch fixes
  o s390: common i/o layer
  o s390: 31 bit compat
  o s390: micro optimizations
  o s390: system tick misaccounting
  o s390: system call restart bug
  o s390: sysfs_create_group
  o s390: Kconfig
  o s390: xpram driver
  o s390: dasd driver
  o s390: dasd partitions
  o s390: tape driver
  o s390: ctc driver
  o s390: iucv driver
  o s390: lcs driver
  o s390: qeth driver
  o s390: vt220 console
  o s390: documentation
  o s390: remove outdated code

Matt Domsch:
  o PCI: make new_id rely on CONFIG_HOTPLUG
  o s/Dell Computer Corporation/Dell Inc./

Matt Mackall:
  o [netdrvr tlan] netif_carrier_* support

Matt Porter:
  o I2C: New PPC4xx I2C driver

Matthew Chapman:
  o ia64: Fix "nosmp" breakage from cpumask patch

Matthew Wilcox:
  o sym53c8xx driver 2.1.18
  o PA-RISC update for 2.6.0-test5
  o Fill in ELF OSABI in ELF headers
  o 1GB stack size limit on PA-RISC
  o fs/exec.c whitespace cleanups
  o interrupt.h needs kernel.h
  o sym53c8xx 2.1.18b
  o zalon & ncr53c8xx cleanups
  o Move EISA_bus
  o [NETFILTER]: Use net/checksum.h instead of asm/checksum.h
  o Kill off sym1

Maximilian Attems:
  o [NETFILTER]: Eliminate duplicate definition in ip_nat.h

Meelis Roos:
  o [SPARC64]: BUG on positive addresses in vga.h

Michal Ludvig:
  o [IPV4]: Fix GRE tunnel device init

Mike Christie:
  o fixes an ide-scsi oops in 2.6-test5

Mirko Lindner:
  o [netdrvr sk98lin] Remove useless configure options
  o [netdrvr sk98lin] small updates
  o [netdrvr sk98lin] update readme, remove old changelog
  o [netdrvr sk98lin] small fixes
  o [netdrvr sk98lin] bump version number
  o [netdrvr sk98lin] fix leaks on error, and related cleanups

Mitchell Blank Jr.:
  o [NET]: Tiny af_packet.c cleanup
  o [SPARC]: Make atomic_read() take const

Nathan Scott:
  o [XFS] Fix a case where we could issue an unwritten extent buffer
    for IO without it being locked, an instant BUG trigger in the block
    layer
  o [XFS] Fix a harmless typo - we were using a pagebuf flag not a bmap
    flag here; fortunately they have the same value (2).
  o [XFS] Tweak last dabuf fix, suggested by Steve, no longer uses
    bitfields but uchars instead
  o [XFS] Use the rounded down size value for all growfs calculations,
    else the last AG can be updated incorrectly
  o [XFS] Implement several additional inode flags - immutable,
    append-only, etc; contributed by Ethan Benson
  o [XFS] Add inode64 mount option; fix case where growfs can push 32
    bit inodes into 64 bit space accidentally - both changes originally
    from IRIX
  o [XFS] Separate the big filesystems macro out into separate big
    inums and blknos macros; fix the check for too-large filesystems in
    the process
  o [XFS] Alternate, cleaner fix for the ENOSPC/ACL lookup problem
  o [XFS] Automatically set logbsize for larger stripe units
  o [XFS] Fix some compile warnings and errors from some long-forgotten
    2.4 mods

Neil Brown:
  o md: Don't setup make_request_fn for md array until *after* it has
    been started
  o md: MODULE_ALIAS for md
  o md: change 'or' to 'plus' in raid1
  o knfsd: Fix cmsg setup for sock_sendmsg in svc_sendto
  o knfsd: NFS4XDR get rid of warning
  o knfsd: idempotent replay cache for OPEN state
  o knfsd: nfsdv4 byte range locking - prepatation
  o knfsd: nfsd byte range locking - LOCK
  o knfsd: nfsdv4 byte range locking - LOCKT
  o knfsd: nfsdv4 byte range locking - LOCKU
  o Fix up initialisation of md devices

Nick Piggin:
  o Badness in as_completed_request warning
  o AS documentation
  o fix AS hangs
  o fix AS crappy performance

Nicolas Kaiser:
  o USB: Remove modules.txt referencea

Nicolas Pitre:
  o [ARM PATCH] 1528/1: big endian support for io-readsb/io-writesb

Oliver Neukum:
  o iforce-usb.c, iforce-packets.c

Patrick Mansfield:
  o don't set underflow for REQ_BLOCK_PC

Patrick Mochel:
  o [power] Fix sysfs state reporting
  o [power] Make sure console level is high when suspending
  o [power] Fix up sysfs state handling
  o [power] Move i386-specific swsusp code to arch/i386/power/
  o [power] swsusp Cleanups
  o [power] Fix device suspend handling
  o [power] Fix handling of pm_users
  o [power] Separate suspend-to-disk from other suspend sequences
  o [power] Make sure devices get added to the PM lists before
    bus_add_device()
  o [acpi] Move register save closer to call to enter sleep state
  o [swsusp] Minor cleanups in read_suspend_image()
  o [swsusp] Use BIO interface when reading from swap
  o [swsusp] Restore software_suspend() call
  o [acpi] Replace /proc/acpi/sleep
  o [power] Whitespace fixes
  o [power] Simplify error handling in pm_suspend_prepare()
  o [power] Make sure we restore interrupts if device_power_down()
    fails
  o [power] Add support for refrigerator to the migration_thread
  o [swsusp] Make sure we call restore_processor_state() when
    suspending
  o [power] Fix swsusp with preempt and clean up
  o [power] Fork swsusp
  o [power] Move PM options into kernel/power/Kconfig
  o [power] Make pmdisk compilable and usable
  o [power] Make pmdisk compile when CONFIG_SOFTWARE_SUSPEND=n
  o [power] Revert swsusp to 2.6.0-test3 state
  o [swsusp] Fix software_suspend() inline return value when
    SOFTWARE_SUSPEND=n
  o [power] Fix ACPI sleep handling with swsusp
  o [power] pmdisk cleanups
  o [power] pmdisk write path cleanups
  o [power] Fix platform devices
  o [power] Remove last panic() from pmdisk
  o [power] Clean up snapshot path in pmdisk
  o [power] Clean up pmdisk page freeing
  o [power] Clean up pmdisk image reading code
  o [power] Get rid of unneeded variables
  o [power] Optimize pmdisk assembly
  o [power] Cleanup pdmisk header
  o [power] Cleanup pmdisk header info
  o [power] Clean up pmdisk pagedir "linking"
  o [power] pmdisk Cleanups
  o [power] Remove unused structure in pmdisk
  o sysfs dput crash fix

Paul Gortmaker:
  o ne2k-pci full duplex with RealTek
  o ne2k_cbus tidy up
  o Remove emacs cruft from 8390 drivers

Paul Mackerras:
  o PPC32: Rework signal code and add a swapcontext system call
  o PPC32: Provide proper siginfo information on various exceptions
  o PPC32: Bitmap operands to find_first/next_bit functions are const
  o PPC32: Fix for highmem on PPC 440
  o PPC32: Update the alignment exception handler for POWER4 processors
  o PPC32: Adjust ucontext to conform with historical practice and with
    glibc
  o PPC32: Fix up the CPU frequency scaling questions in
    arch/ppc/Kconfig
  o PPC32: Fix the definition of PMU_IOC_GRAB_BACKLIGHT
  o PPC32: Make scripts/mkuboot.sh executable

Pete Zaitcev:
  o USB: Drop debounce printout for 2.6
  o [SPARC]: One more multi-line string, from Rob Radez
  o [SPARC]: Down with P3's in srmmu.c

Peter Chubb:
  o ia64: unwind.c fix for spinlock-debug compilation

Peter Osterlund:
  o synaptics.c, psmouse-base.c
  o Input: Big Synaptics update
  o psmouse-base.c
  o input: Tidy up events reported by a Synaptics pad, add touchpad
    support to mousedev.
  o input: Fix broken handling of rotated Synaptics touchpads

Randy Dunlap:
  o tr/olympic probe: remove #warning, improve error handling
  o enable aha152x to build when AHA152X_DEBUG is defined
  o [WAN]: Remove multi-line string literal
  o [WAN]: Convert taskqueues to workqueues
  o [WAN]: Use module_exit() in sdladrv
  o [NET]: Remove unneeded includes (tokenring)
  o [NET]: Remove unneeded includes (skfp)
  o [NET]: Remove unneeded includes (sk98lin)
  o [NET]: Remove unneeded includes (wan, from Randy Hron)
  o [NET]: Remove unneeded includes (hamradio, from Randy Hron)
  o [NET]: Remove unneeded includes (wireless, from Randy Hron)
  o [NET]: Remove unneeded includes (wanrouter, from Randy Hron)
  o [SPARC]: Remove unneeded includes (from Randy Hron)
  o janitor: remove unneeded includes (tokenring)
  o janitor: remove unneeded includes (sk98lin)
  o janitor: remove (or add) unneeded includes
  o janitor: remove unneeded includes (skfp)
  o janitor: remove (or add) unneeded includes (wireless)
  o janitor: remove unneeded includes (hamradio)
  o janitor: remove (or add) unneeded includes (drivers/net/)
  o janitor: insert a missing iounmap()
  o janitor: ns83820 error handling
  o floppy I/O error handling => Oops
  o janitor: remove unneeded includes (/scsi/)
  o janitor: sg_register error handling
  o [BLUETOOTH]: Remove unneeded verify_area call (from
    domen@coderock.org)
  o janitor: cleanup includes in dpt_i2o
  o janitor: cleanup includes in in2000
  o jantior: sx: use get/put_user (remove verify_area)
  o janitor: scsi/a3000: cleanup includes
  o janitor: isdn: remove unneeded verify_area calls
  o janitor: cleanup includes in fs/
  o janitor: rio_linux: user get/put_user for errors (not
  o janitor: clean up newlines
  o jantior: coda: userspace error handling
  o janitor: h8300: put_user for error handling
  o janitor: cleanup includes in tc/zs
  o janitor: isdn: remove verify_area calls
  o janitor: intermezzo: clean up #includes
  o janitor: serial/tx3912: remove unneeded verify_area calls
  o janitor: cleanup includes in megaraid
  o janitor: cleanup includes in osst
  o janitor: cleanup includes in sym53c416
  o janitor: hermes: delete verify_area call
  o janitor: e100: cleanup #includes

Randy Hron:
  o I2C: drivers/i2c version.h cleanup
  o [PATCH] drivers/usb version/include cleanup

Ricky Beam:
  o [SPARC64]: Fix VT/VT_CONSOLE Kconfig for headless operation

Rob Radez:
  o [SPARC32]: Non-controversial gcc-3.3 build fixes

Roland McGrath:
  o PROT_GROWSDOWN/PROT_GROWSUP flags for mprotect

Rolf Eike Beer:
  o Fix typo in fs/Kconfig

Russell Cattelan:
  o [XFS] IRIX sets KM_SLEEP to 0 but the support routines sets
    KM_SLEEP to 1
  o [XFS] Fix from Christoph

Russell King:
  o [SERIAL] Add new port numbers
  o [SERIAL] Rename core.o and 8250_cs.o
  o [PCMCIA] Remove SS_DEBOUNCED
  o [PCMCIA] Remove a set of unused definitions
  o [PCMCIA] Drop level argument from pcmcia_socket_dev_* calls
  o [PCMCIA] Remove incorrect/misleading/old comments from cardbus.c
  o [PCMCIA] Remove editor droppings
  o [SERIAL] Drop "level" argument from serial PM calls
  o [SERIAL] Convert serial config deps to select statements
  o [SERIAL] Fix another missing irqreturn_t (clps711x.c)
  o [SERIAL] Introduce per-port capabilities
  o stable AGP pci_device_id tables
  o More buggy pci drivers
  o [ARM] Update SA1111
  o [ARM] Remove compiler warning in sa1111-pcipool.c
  o [ARM] Update ARM CPU support
  o [ARM] Detect and fix up CPUs with non-coherent write buffers
  o [ARM] Provide __HAVE_ARCH_BCOPY
  o [ARM] Add newly discovered CR register function
  o [ARM] Fix gcc3 multi-line string literal build error
  o [ARM] Remove CONFIG_KBDMOUSE from arch/arm/Kconfig
  o [ARM] Kill gcc preprocessor warning
  o [ARM] Fix name of "cache format" cpuinfo description
  o [ARM] Provide bus type and support for logic modules
  o [ARM] Clean up PCI error reporting
  o [ARM] Dynamically allocate SA1111 component devices
  o [ARM] Update machine types list
  o [ARM] Ensure that MM initialisation warnings are reported as bugs
  o [PCMCIA] Fix bug in PCMCIA resource management memory probing
  o Make /proc/kcore configurable
  o [ARM] Massive rename of default configuration files
  o [ARM] Remove private %_config makefile rule
  o [ARM] Correct comments for abort handler parameters
  o [ARM] Fix abort handler typo affecting Xscale CPUs
  o [ARM] Place initial data/code in assembly into the correct section
  o [ARM] Optimise io-readsb for CPUs with delay slots after ldr
  o [ARM] Optimise io-writesl for cpus with ldr result delays
  o [ARM] Fix AMBA keyboard/mouse driver
  o [ARM] Update mach-types with latest version
  o [ARM] Update bootp kernel+initrd loader
  o [ARM] Fix up includes
  o [ARM] Avoid using clone syscall from kernel_thread()
  o [PCMCIA] Fix deadlocks caused between PCMCIA card fix and device
    model
  o [ARM] Fix page table spinlocking
  o [ARM] Remove CONFIG_PCI_INTEGRATOR
  o [ARM] Don't use pci_find_device in interrupt context

Rusty Russell:
  o Remove modules.txt
  o [NETFILTER]: MASQUERADE target for mostly-static IP addresses
  o [NETFILTER]: REJECT nonlinear fixes after sync with 2.4
  o Kconfig fixes for modules.txt
  o Futex lock division
  o Futex hash improv and minor cleanups
  o Remove modules.txt references
  o [PATCH 2.6.0-test1] remove check_region from drivers_net_3c509.c

Sam Ravnborg:
  o kbuild: Save relevant parts of modules.txt
  o bk: Ignore scripts/bin2c
  o kconfig: Allow architectures to select board specific configs
  o kbuild: Build minimum in scripts/ when changing configuration
  o kbuild: Remove cscope.out during make mrproper
  o kbuild/ppc*: Remove obsolete _config support
  o kbuild: Separate output directory
  o kbuild: Escape "'" in cmd macro
  o kbuild/rpm: Fix 'make rpm' and enable use of 'make O=dir rpm'
  o kbuild: modpost, corrected check of mmap()

Scott Feldman:
  o [e1000] new 82541/5/6/7 hardware support
  o [e1000] 82544 PCI-X hang fix + TSO updates
  o [e1000] Turn off ASF support on Fiber nics
  o [e1000] read correct bit from EEPROM for getting WoL settings
  o [e1000] add ethtool flow control support
  o [e1000] make function our of setting media type
  o [e1000] cleanup error return codes
  o [e1000] move static to table from .h to .c
  o [e1000] Add PHY master/slave #define override
  o [e1000] misc whitespace cleanup, changelog
  o [e1000] flow control updates
  o [e1000] force 1000/full on SERDES connected to back-plane
  o [e1000] better propagation of error codes
  o [e1000] misc
  o [e100] PRO/10+ not configured properly
  o [e100] h/w can't do IPv6 checksum offloading
  o [e100] trying to pci_alloc before pci_enable

Simon Kelley:
  o atmel wireless driver

Stephen Hemminger:
  o Get rid of Intermezzo warning
  o Fix modularization of Siemens line discipline
  o fix build of cosa
  o (1/4) sdla - move out of Space.c
  o (2/4) get rid of register_frad
  o (3/4) dlci locking and registration changes
  o (4/4) dlci netdevice event handling
  o (5/4) dlci netdevice event handling
  o [NET]: Remove some unnecessary proc_fs.h includes
  o [NET]: Convert packet scheduler API to seq_file
  o [BRIDGE]: Clear hw checksum flags when bridging
  o [NET]: Better proc_net macros for non-procfs case
  o [IPVS]: Convert to seq_file
  o use seq_lock for monotonic time
  o drivers/char/misc -- use list() macros
  o drivers/char/misc -- seq_file
  o [IPV4]: In tcp_diag.c, use static, const, and void *, as
    appropriate
  o [IRDA]: Eliminate skb_linearize() from irda
  o [IRDA]: proc/net/irda files using seq_file
  o [IRDA]: Convert ircomm to seq_file
  o [NET]: More const in skbuff.h
  o [IPVS]: Get rid of register declarations
  o [IPVS]: Get rid of SEQ_START_TOKEN define
  o [IPVS]: Use list_for_each_entry macro
  o [IPVS]: Use time_before/after
  o [NET]: Deprecate dev_get()
  o [NET]: Fix bug in dev_get() deprecation patch
  o replace sppp_of macro with inline
  o get rid of old IRDA drivers
  o [IrDA] irda-usb -- dev_alloc cleanout
  o [IrDA] w83977af -- dev_alloc cleanout
  o [IrDA] donahoboe -- dev_alloc cleanout
  o [IrDA] nsc-ircc -- dev_alloc cleanout
  o [IrDA] via-ircc -- dev_alloc cleanout
  o [IrDA] ali-ircc -- dev_alloc cleanout
  o sealevel wan driver
  o update arcnet/pcmcia driver
  o hamradio/scc -
  o Road Runner HIPPI driver (rrunner)
  o [IPVS]: Fix errors in list_for_each changes
  o [NET]: rtnetlink -- rtattr_strcmp const args
  o [NET]: rtnetlink -- RTA_PUT unlikely
  o [NET]: rtnetlink -- ASSERT_RTNL and BUG_TRAP
  o [NET]: No need for alloc_divert_blk in Space.c
  o [NET]: Fix inaccurate comments in Space.c
  o [NET]: Fix boot param string setup in Space.c
  o [LLC]: llc_output.c needs linux/trdevice.h
  o (1/8) arlan -- merge arlan-proc with main code
  o (2/8) arlan -- get rid of some dead wood
  o (3/8) arlan -- get rid of unnecessary casts
  o (4/8) arlan -- trailing semicolons
  o (5/8) arlan -- more set never used elements
  o (6/8) arlan -- add spinlock
  o (7/8) arlan -- more dead wood removal
  o (8/8) arlan -- proper jiffies usage
  o (1/4) Update baycom drivers for 2.6
  o (2/4) baycom c99 initializers
  o (3/4) baycom/hdlcdrv unregister
  o [IPV4]: Convert ipmr to seq_file
  o [netdrvr sk98lin] build on smp fix
  o [netdrvr skge] handle proc_fs errors
  o [netdrvr sk98lin] use seq_file for /proc
  o sealevel -- syncppp startup fix
  o wan/z8530 deadlocks

Stephen Lord:
  o [XFS] fix up xfs_lowbit's use of ffs
  o [XFS] Some tweaks to the additional inode flags, suggested by Ethan
    Benson
  o [XFS] fix build for gcc 3.2
  o [XFS] Fix initialization of inode flags from xfs inode fields
  o [XFS] Make xfs_ichgtime call mark_inode_dirty_sync instead of
    mark_inode_dirty makes the just the inode look dirty, and not the
    inode and the data.

Steven Dake:
  o fix kernel BUG using multipath

Stéphane Eranian:
  o ia64: perfmon2 update
  o ia64: perfmon2 update
  o ia64: minor perfmon2 patch
  o ia64: pass si_isr for a few more signal sources

Suresh B. Siddha:
  o ia64: fix typo in spinlock.h

Timothy Shimmin:
  o [XFS]  Change xlog_verify_iclog() to use idx as zero based instead

Tom Rini:
  o PPC32: Add _IO{R,W,WR}_BAD and update _IO{R,W,WR}
  o PPC32: Allow for boards to flush / disable L2 / L3 in the
    bootwrapper
  o PPC32: Remove trailing blanks from PPC32 files
  o PPC32: Two minor bootwrapper fixes on PReP, from Hollis Blanchard
    <hollisb@us.ibm.com>
  o PPC32: Merge MPC8260 board selection with other 'classic PPC'
    boards
  o PPC32: Fix the udelay implementation in the bootwrapper
  o PPC32: Make include/asm-ppc/processor.h more readable
  o PPC32: Fix the dependancies on CONFIG_ISA
  o PPC32: Fix another incorrect asm statement
  o PPC32: Move all register definitions to include/asm-ppc/reg.h
  o PPC32: Audit <asm/processor.h> uses
  o PPC32: Fix a rounding error in the bootwrapper udelay
  o PPC32: Re-arrange arch/ppc/Kconfig, from Hollis Blanchard
    <hollis@penguinppc.org>
  o PPC32: Make the IBM 4xx options menu depend on 4xx, from Hollis
    Blanchard <hollis@penguinppc.org>
  o PPC32: Make CONFIG_DEBUG_INFO default to n, always
  o PPC32: Minor cleanups
  o PPC32: Move PowerPC Book E (and IBM 40x) register definitions to
    their own fil e.
  o PPC32: Cleanup of SPR handling in ppc_htab.c
  o PPC32: Further cleanups to the ppc_htab code
  o PPC32: Add a uImage boot target

Tony Luck:
  o ia64: fix PM config option
  o ia64: trim.bottom trims the wrong entry

Urban Widmark:
  o smbfs module unload and highuid

Vinay K. Nallamothu:
  o [NETROM]: Timer code cleanup

Vojtech Pavlik:
  o input.c
  o db9.c
  o psmouse-base.c
  o psmouse-base.c
  o input.h, keyboard.c, evdev.c
  o psmouse-base.c
  o input: Fix memory leak in hiddev.c found by Stanford Checker
  o Fix a warning in input.c when CONFIG_PROC_FS is not set
  o Remove a not necessary #ifdef CONFIG_PROC_FS/#endif in input.c
  o Fix memory leak in hiddev.c found by Stanford Checker
  o input: Revert synaptics->pktcnt change. New synaptics driver
    actually uses the variable.
  o input: Change AT keyboard to use hardware autorepeat and move
    untranslating to the AT keyboard driver as well. Lower PS/2 mouse
    default report rate. Fix repeat rate adjustment ioctls accordingly,
    and update other files to reflect the changes. This should fix most
    known keyboard problems in 2.6.
  o input: Add BTN_TOUCH to Synaptics pad driver. This fixes the joydev
    grabbing of the pads, as well as simplifies the mousedev driver.

Wensong Zhang:
  o [IPVS]: Make __ip_vs_svc_lock local and use __user tags

Will Cohen:
  o ia64: oprofile support



^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28  1:27 Linux 2.6.0-test6 Linus Torvalds
@ 2003-09-28  7:03 ` Con Kolivas
  2003-09-28 10:02   ` Rob Landley
  2003-09-28  8:26 ` Markus Hästbacka
                   ` (8 subsequent siblings)
  9 siblings, 1 reply; 128+ messages in thread
From: Con Kolivas @ 2003-09-28  7:03 UTC (permalink / raw)
  To: Kernel Mailing List

On Sun, 28 Sep 2003 11:27, Linus Torvalds wrote:
> from Andrew Morton. Most notably perhaps Con's scheduler changes that have
> been discussed extensively and made it into the -mm tree for testing.

For those who are trying this for the first time, please note that the 
scheduler has been tuned to tell the difference between tasks of the _same_ 
nice level. This means do NOT renice X or it will make audio skip unless you 
also renice your audio application by the same amount. Lots of distributions 
have done this for the old 2.4 scheduler which could not treat equal "nice" 
levels as differently as the new scheduler does and 2.6 shouldn't need 
special treatment.

So for testing note the following points:

Make sure X is NOT reniced to -10 as many distributions are doing.
Some shells spawn processes at nice +5 by default and this will make audio 
apps suffer.
Make sure your hard disk, graphics card and audio card are performing at equal 
standard to your 2.4 kernel (ie dma is working, graphics is fully accelerated 
etc).

before commenting on audio performance.

Con


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28  1:27 Linux 2.6.0-test6 Linus Torvalds
  2003-09-28  7:03 ` Con Kolivas
@ 2003-09-28  8:26 ` Markus Hästbacka
  2003-09-28 10:54   ` Jeff Garzik
  2003-09-28  8:59 ` keyboard repeat / sound [was Re: Linux 2.6.0-test6] Roger Luethi
                   ` (7 subsequent siblings)
  9 siblings, 1 reply; 128+ messages in thread
From: Markus Hästbacka @ 2003-09-28  8:26 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Kernel Mailinglist

[-- Attachment #1: Type: text/plain, Size: 607 bytes --]

CC [M]  drivers/net/wireless/arlan-main.o
drivers/net/wireless/arlan-main.c: In function `init_module':
drivers/net/wireless/arlan-main.c:1923: error: `probe' undeclared (first
use in this function)
drivers/net/wireless/arlan-main.c:1923: error: (Each undeclared
identifier is reported only once
drivers/net/wireless/arlan-main.c:1923: error: for each function it
appears in.)
make[3]: *** [drivers/net/wireless/arlan-main.o] Error 1
make[2]: *** [drivers/net/wireless] Error 2
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2

Regards,
----
Markus Hästbacka <midian@ihme.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 128+ messages in thread

* keyboard repeat / sound [was Re: Linux 2.6.0-test6]
  2003-09-28  1:27 Linux 2.6.0-test6 Linus Torvalds
  2003-09-28  7:03 ` Con Kolivas
  2003-09-28  8:26 ` Markus Hästbacka
@ 2003-09-28  8:59 ` Roger Luethi
  2003-09-29 15:16   ` Vojtech Pavlik
  2003-09-28 10:09 ` Linux 2.6.0-test6 Rafał 'rmrmg' Roszak
                   ` (6 subsequent siblings)
  9 siblings, 1 reply; 128+ messages in thread
From: Roger Luethi @ 2003-09-28  8:59 UTC (permalink / raw)
  To: Kernel Mailing List

With test6, keyboard repeat takes very noticably longer to kick in after X
has been started (for both X and console). In test5, starting X makes no
difference.

Also, if you move your test5 .config forward and lose sound, you may find
that you now have to enable gameport in input devices to be able to select
(and thus, compile) your sound card driver.

On the up side, the scheduler changes make the infamous xmms skips go away
(for my purposes).

Roger

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28  7:03 ` Con Kolivas
@ 2003-09-28 10:02   ` Rob Landley
  2003-09-29  4:55     ` Nick Piggin
  0 siblings, 1 reply; 128+ messages in thread
From: Rob Landley @ 2003-09-28 10:02 UTC (permalink / raw)
  To: Con Kolivas, Kernel Mailing List

On Sunday 28 September 2003 02:03, Con Kolivas wrote:
> On Sun, 28 Sep 2003 11:27, Linus Torvalds wrote:
> > from Andrew Morton. Most notably perhaps Con's scheduler changes that
> > have been discussed extensively and made it into the -mm tree for
> > testing.
>
> For those who are trying this for the first time, please note that the
> scheduler has been tuned to tell the difference between tasks of the _same_
> nice level. This means do NOT renice X or it will make audio skip unless
> you also renice your audio application by the same amount. Lots of
> distributions have done this for the old 2.4 scheduler which could not
> treat equal "nice" levels as differently as the new scheduler does and 2.6
> shouldn't need special treatment.
>
> So for testing note the following points:
>
> Make sure X is NOT reniced to -10 as many distributions are doing.
> Some shells spawn processes at nice +5 by default and this will make audio
> apps suffer.
> Make sure your hard disk, graphics card and audio card are performing at
> equal standard to your 2.4 kernel (ie dma is working, graphics is fully
> accelerated etc).

I.E. with your new scheduler, priority levels actually have enough of an 
effect now that things that aren't reniced can be noticeably starved by 
things that are.

This is, in point of fact, progress.  If you nice X to -10, X will hog the CPU 
to update the display, potentially starving your audio output process enough 
to cause skips.  This is not a bug, this is what you asked the system to do.  
Don't Do That Then.

Rob

(Renicing X can even make the display jittery if the application can't 
promptly get CPU time to respond to redraw requests or mouse movement events 
because X is busy doing things like issuing more redraw requests and mouse 
movement events... :)

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28  1:27 Linux 2.6.0-test6 Linus Torvalds
                   ` (2 preceding siblings ...)
  2003-09-28  8:59 ` keyboard repeat / sound [was Re: Linux 2.6.0-test6] Roger Luethi
@ 2003-09-28 10:09 ` Rafał 'rmrmg' Roszak
  2003-09-28 11:05 ` Andreas Jellinghaus
                   ` (5 subsequent siblings)
  9 siblings, 0 replies; 128+ messages in thread
From: Rafał 'rmrmg' Roszak @ 2003-09-28 10:09 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 967 bytes --]

#v+
  CC [M]  drivers/isdn/i4l/isdn_net_lib.o
  CC [M]  drivers/isdn/i4l/isdn_fsm.o
  CC [M]  drivers/isdn/i4l/isdn_tty.o
drivers/isdn/i4l/isdn_tty.c: In function `isdn_tty_write':
drivers/isdn/i4l/isdn_tty.c:1198: warning: unused variable `m'
drivers/isdn/i4l/isdn_tty.c:1790:10: warning: #warning need fixing
/kkeil  CC [M]  drivers/isdn/i4l/isdn_v110.o
  CC [M]  drivers/isdn/i4l/isdn_common.o
drivers/isdn/i4l/isdn_common.c:806:2: warning: #warning FIXME divert
interface drivers/isdn/i4l/isdn_common.c: In function `isdn_init':
drivers/isdn/i4l/isdn_common.c:2223: error: label `err_tty_modem' used
but not defined make[3]: *** [drivers/isdn/i4l/isdn_common.o] Błąd 1
make[2]: *** [drivers/isdn/i4l] Błąd 2
make[1]: *** [drivers/isdn] Błąd 2
make: *** [drivers] Błąd 2
#v-


-- 
registered Linux user 261525 | Wszystko jest trudne przy
gg 2311504________rmrmg@wp.pl|    odpowiednim stopniu
RMRMG signature version 0.0.2|        abstrakcji

[-- Attachment #2: .config --]
[-- Type: application/octet-stream, Size: 22490 bytes --]

#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_STANDALONE=y
CONFIG_BROKEN_ON_SMP=y

#
# General setup
#
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_IKCONFIG is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y

#
# Processor type and features
#
CONFIG_X86_PC=y
# 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 is not set
# CONFIG_X86_ES7000 is not set
# 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 is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# CONFIG_MK8 is not set
# CONFIG_MELAN is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_XCHGADD_ALGORITHM=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_USE_3DNOW=y
# CONFIG_HPET_TIMER is not set
# CONFIG_HPET_EMULATE_RTC is not set
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
CONFIG_X86_MCE_P4THERMAL=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
# CONFIG_EDD is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
# CONFIG_SOFTWARE_SUSPEND is not set
# CONFIG_PM_DISK is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
# CONFIG_ACPI_HT is not set
# CONFIG_ACPI is not set

#
# APM (Advanced Power Management) BIOS Support
#
CONFIG_APM=m
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
# CONFIG_APM_CPU_IDLE is not set
# CONFIG_APM_DISPLAY_BLANK is not set
# CONFIG_APM_RTC_IS_GMT is not set
# CONFIG_APM_ALLOW_INTS is not set
CONFIG_APM_REAL_MODE_POWER_OFF=y

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
# CONFIG_HOTPLUG is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y

#
# Generic Driver Options
#

#
# Memory Technology Devices (MTD)
#
# 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_ISAPNP is not set
# CONFIG_PNPBIOS is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# 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_LOOP=m
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_SIZE=4096
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_LBD is not set

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
# CONFIG_IDEDISK_STROKE is not set
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_IDE_TASK_IOCTL is not set
CONFIG_IDE_TASKFILE_IO=y

#
# IDE chipset support/bugfixes
#
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDE_TCQ is not set
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_IDEDMA_PCI_WIP is not set
CONFIG_BLK_DEV_ADMA=y
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
CONFIG_BLK_DEV_AMD74XX=y
# 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_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_PIIX 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_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_DMA_NONPCI is not set
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
CONFIG_SCSI=y
# CONFIG_SCSI_PROC_FS is not set

#
# SCSI support type (disk, tape, CD-ROM)
#
# CONFIG_BLK_DEV_SD is not set
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_REPORT_LUNS is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set

#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_MEGARAID is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_CPQFCTS is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#

#
# IEEE 1394 (FireWire) support (EXPERIMENTAL)
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
CONFIG_I2O=m
CONFIG_I2O_PCI=m
CONFIG_I2O_BLOCK=m
CONFIG_I2O_SCSI=m
CONFIG_I2O_PROC=m

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETLINK_DEV is not set
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP 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_INET_ECN 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

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# IP: Netfilter Configuration
#
# CONFIG_IP_NF_CONNTRACK is not set
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=m
# CONFIG_IP_NF_MATCH_LIMIT is not set
# CONFIG_IP_NF_MATCH_IPRANGE is not set
# CONFIG_IP_NF_MATCH_MAC is not set
# CONFIG_IP_NF_MATCH_PKTTYPE is not set
# CONFIG_IP_NF_MATCH_MARK is not set
# CONFIG_IP_NF_MATCH_MULTIPORT 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_DSCP is not set
# CONFIG_IP_NF_MATCH_AH_ESP is not set
# CONFIG_IP_NF_MATCH_LENGTH is not set
# CONFIG_IP_NF_MATCH_TTL is not set
# CONFIG_IP_NF_MATCH_TCPMSS is not set
# CONFIG_IP_NF_MATCH_OWNER is not set
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
# CONFIG_IP_NF_MANGLE is not set
# CONFIG_IP_NF_TARGET_LOG is not set
# CONFIG_IP_NF_TARGET_ULOG is not set
# CONFIG_IP_NF_TARGET_TCPMSS is not set
# CONFIG_IP_NF_ARPTABLES is not set
# CONFIG_IP_NF_COMPAT_IPCHAINS is not set
# CONFIG_IP_NF_COMPAT_IPFWADM is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IPV6_SCTP__=y
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_VLAN_8021Q 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_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
CONFIG_NETDEVICES=y

#
# ARCnet devices
#
# CONFIG_ARCNET is not set
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_NET_SB1000 is not set

#
# Ethernet (10 or 100Mbit)
#
# CONFIG_NET_ETHERNET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set
# CONFIG_NET_FC is not set
# CONFIG_RCPCI is not set
# CONFIG_SHAPER is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set

#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set

#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set

#
# Bluetooth support
#
# CONFIG_BT is not set

#
# ISDN subsystem
#
CONFIG_ISDN_BOOL=y

#
# Old ISDN4Linux
#
CONFIG_ISDN=m
# CONFIG_ISDN_NET_SIMPLE is not set
# CONFIG_ISDN_NET_CISCO is not set
CONFIG_ISDN_PPP=y
# CONFIG_ISDN_PPP_VJ is not set
CONFIG_ISDN_MPP=y
CONFIG_ISDN_PPP_BSDCOMP=m
# CONFIG_ISDN_AUDIO is not set

#
# ISDN feature submodules
#
# CONFIG_ISDN_DRV_LOOP is not set

#
# CAPI subsystem
#
# CONFIG_ISDN_CAPI is not set

#
# ISDN4Linux hardware drivers
#

#
# Passive cards
#
CONFIG_ISDN_DRV_HISAX=m

#
# D-channel protocol features
#
CONFIG_HISAX_EURO=y
# CONFIG_DE_AOC is not set
# CONFIG_HISAX_NO_SENDCOMPLETE is not set
# CONFIG_HISAX_NO_LLC is not set
# CONFIG_HISAX_NO_KEYPAD is not set
# CONFIG_HISAX_1TR6 is not set
# CONFIG_HISAX_NI1 is not set
CONFIG_HISAX_MAX_CARDS=8

#
# HiSax supported cards
#
# CONFIG_HISAX_16_3 is not set
# CONFIG_HISAX_TELESPCI is not set
# CONFIG_HISAX_S0BOX is not set
CONFIG_HISAX_FRITZPCI=y
# CONFIG_HISAX_AVM_A1_PCMCIA is not set
# CONFIG_HISAX_ELSA is not set
# CONFIG_HISAX_DIEHLDIVA is not set
# CONFIG_HISAX_SEDLBAUER is not set
# CONFIG_HISAX_NETJET is not set
# CONFIG_HISAX_NETJET_U is not set
# CONFIG_HISAX_NICCY is not set
# CONFIG_HISAX_BKM_A4T is not set
# CONFIG_HISAX_SCT_QUADRO is not set
# CONFIG_HISAX_GAZEL is not set
# CONFIG_HISAX_HFC_PCI is not set
# CONFIG_HISAX_W6692 is not set
# CONFIG_HISAX_HFC_SX is not set
# CONFIG_HISAX_ENTERNOW_PCI is not set
# CONFIG_HISAX_DEBUG is not set
# CONFIG_HISAX_FRITZ_PCIPNP is not set
# CONFIG_HISAX_HFCPCI is not set

#
# Active cards
#
# CONFIG_ISDN_DRV_EICON is not set
# CONFIG_ISDN_DRV_TPAM is not set
# CONFIG_HYSDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# 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 is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
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

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_PS2_SYNAPTICS is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_CONSOLE is not set
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256

#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m

#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_ELEKTOR is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
CONFIG_I2C_NFORCE2=m
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set

#
# I2C Hardware Sensors Chip support
#
CONFIG_I2C_SENSOR=m
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_EEPROM=m
CONFIG_SENSORS_IT87=m
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM85=m
CONFIG_SENSORS_VIA686A=m
CONFIG_SENSORS_W83781D=m

#
# Mice
#
# CONFIG_BUSMOUSE is not set
# CONFIG_QIC02_TAPE is not set

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
CONFIG_RTC=m
CONFIG_GEN_RTC=m
# CONFIG_GEN_RTC_X is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=m
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
# CONFIG_AGP_INTEL is not set
CONFIG_AGP_NVIDIA=m
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
CONFIG_DRM=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_GAMMA is not set
# CONFIG_DRM_R128 is not set
CONFIG_DRM_RADEON=m
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HANGCHECK_TIMER is not set

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m

#
# Video For Linux
#

#
# Video Adapters
#
CONFIG_VIDEO_BT848=m
# CONFIG_VIDEO_CPIA is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_TUNER_3036 is not set
# CONFIG_VIDEO_STRADIS is not set
# CONFIG_VIDEO_ZORAN is not set
# CONFIG_VIDEO_SAA7134 is not set
# CONFIG_VIDEO_MXB is not set
# CONFIG_VIDEO_DPC is not set
# CONFIG_VIDEO_HEXIUM_ORION is not set
# CONFIG_VIDEO_HEXIUM_GEMINI is not set

#
# Radio Adapters
#
# CONFIG_RADIO_GEMTEK_PCI is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_MAESTRO is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
CONFIG_VIDEO_VIDEOBUF=m
CONFIG_VIDEO_TUNER=m
CONFIG_VIDEO_BUF=m
CONFIG_VIDEO_BTCX=m

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
CONFIG_EXT3_FS=y
# CONFIG_EXT3_FS_XATTR is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=m
CONFIG_UDF_FS=m

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
# CONFIG_DEVFS_FS is not set
CONFIG_DEVPTS_FS=y
# CONFIG_DEVPTS_FS_XATTR is not set
CONFIG_TMPFS=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_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 is not set
# CONFIG_NFSD is not set
# CONFIG_EXPORTFS is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_INTERMEZZO_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y

#
# Native Language Support
#
CONFIG_NLS_DEFAULT="iso8859-2"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
CONFIG_NLS_CODEPAGE_852=m
# 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=m
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ISO8859_1 is not set
CONFIG_NLS_ISO8859_2=m
# 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 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=m

#
# Graphics support
#
CONFIG_FB=y
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
CONFIG_FB_VESA=y
CONFIG_VIDEO_SELECT=y
# CONFIG_FB_HGA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_VIRTUAL is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE is not set

#
# Logo configuration
#
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y

#
# Sound
#
CONFIG_SOUND=y

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=y
CONFIG_SND_SEQUENCER=y
# CONFIG_SND_SEQ_DUMMY is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_SEQUENCER_OSS=y
# CONFIG_SND_RTCTIMER is not set
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set

#
# PCI devices
#
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_AZT3328 is not set
CONFIG_SND_EMU10K1=m
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
CONFIG_SND_INTEL8X0=m
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VX222 is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
# CONFIG_USB is not set
# CONFIG_USB_GADGET is not set
# CONFIG_USB_NET2280 is not set
# CONFIG_USB_ZERO is not set
# CONFIG_USB_ETH is not set
# CONFIG_USB_GADGETFS is not set

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_IOVIRT is not set
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_FRAME_POINTER is not set
CONFIG_X86_EXTRA_IRQS=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y

#
# Security options
#
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
# CONFIG_CRYPTO is not set

#
# Library routines
#
CONFIG_CRC32=y
CONFIG_ZLIB_INFLATE=m
CONFIG_X86_BIOS_REBOOT=y

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28  8:26 ` Markus Hästbacka
@ 2003-09-28 10:54   ` Jeff Garzik
  0 siblings, 0 replies; 128+ messages in thread
From: Jeff Garzik @ 2003-09-28 10:54 UTC (permalink / raw)
  To: Markus Hästbacka; +Cc: Linus Torvalds, Kernel Mailinglist

Markus Hästbacka wrote:
> CC [M]  drivers/net/wireless/arlan-main.o
> drivers/net/wireless/arlan-main.c: In function `init_module':
> drivers/net/wireless/arlan-main.c:1923: error: `probe' undeclared (first
> use in this function)
> drivers/net/wireless/arlan-main.c:1923: error: (Each undeclared
> identifier is reported only once
> drivers/net/wireless/arlan-main.c:1923: error: for each function it
> appears in.)
> make[3]: *** [drivers/net/wireless/arlan-main.o] Error 1
> make[2]: *** [drivers/net/wireless] Error 2
> make[1]: *** [drivers/net] Error 2
> make: *** [drivers] Error 2


already fixed... change headed to Linus soon.


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28  1:27 Linux 2.6.0-test6 Linus Torvalds
                   ` (3 preceding siblings ...)
  2003-09-28 10:09 ` Linux 2.6.0-test6 Rafał 'rmrmg' Roszak
@ 2003-09-28 11:05 ` Andreas Jellinghaus
  2003-09-28 12:34   ` Dave Jones
  2003-09-28 16:42 ` Ivan Gyurdiev
                   ` (4 subsequent siblings)
  9 siblings, 1 reply; 128+ messages in thread
From: Andreas Jellinghaus @ 2003-09-28 11:05 UTC (permalink / raw)
  To: linux-kernel

test6 (plus hostap patch) hangs during boot.
The last line I see is 
cpufreq: Intel(R) SpeedStep(TM) for this chip set not (yet) available.

and with test5 the next line would be:
IA-32 Microcode Update Driver: v1.11 <tigran@veritas.com>

booted with parameters:
kernel /vmlinuz-2.6.0-test6 root=/dev/hda2 ro hda=2432,255,63 resume=/dev/hda3
elevator=deadline psmouse_noext

but without the last three params it didn't change anything.

any idea?

Andreas

machine is a p3, dell latitude c600, lspci:
00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03)
00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03)
00:03.0 CardBus bridge: Texas Instruments PCI1420
00:03.1 CardBus bridge: Texas Instruments PCI1420
00:07.0 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:08.0 Multimedia audio controller: ESS Technology ES1983S Maestro-3i PCI Audio Accelerator (rev 10)
00:10.0 Ethernet controller: 3Com Corporation 3c556 Hurricane CardBus (rev 10)
00:10.1 Communication controller: 3Com Corporation Mini PCI 56k Winmodem (rev 10)
01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility M3 AGP 2x (rev 02)

 cat /proc/cpuinfo 
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 8
model name      : Pentium III (Coppermine)
stepping        : 10
cpu MHz         : 701.620
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips        : 1388.54

config:
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSCTL=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_KALLSYMS=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_KMOD=y
CONFIG_X86_PC=y
CONFIG_MPENTIUMIII=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_RWSEM_XCHGADD_ALGORITHM=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_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_PREEMPT=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
CONFIG_I8K=y
CONFIG_MICROCODE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_EDD=y
CONFIG_NOHIGHMEM=y
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_PM=y
CONFIG_SOFTWARE_SUSPEND=y
CONFIG_PM_DISK=y
CONFIG_PM_DISK_PARTITION="hda3"
CONFIG_ACPI_HT=y
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_BUS=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_X86_ACPI_CPUFREQ=y
CONFIG_X86_SPEEDSTEP_CENTRINO=y
CONFIG_X86_SPEEDSTEP_ICH=y
CONFIG_X86_SPEEDSTEP_SMI=y
CONFIG_X86_SPEEDSTEP_LIB=y
CONFIG_X86_P4_CLOCKMOD=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
CONFIG_ISA=y
CONFIG_HOTPLUG=y
CONFIG_PCMCIA=y
CONFIG_YENTA=y
CONFIG_CARDBUS=y
CONFIG_I82092=y
CONFIG_I82365=y
CONFIG_TCIC=y
CONFIG_PCMCIA_PROBE=y
CONFIG_HOTPLUG_PCI=y
CONFIG_HOTPLUG_PCI_ACPI=y
CONFIG_BINFMT_ELF=y
CONFIG_FW_LOADER=y
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
CONFIG_PARPORT_PC_CML1=y
CONFIG_PARPORT_1284=y
CONFIG_PNP=y
CONFIG_PNPBIOS=y
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=y
CONFIG_BLK_DEV_NBD=y
CONFIG_LBD=y
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECS=m
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDEFLOPPY=y
CONFIG_IDE_TASKFILE_IO=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_ADMA=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_NET_KEY=y
CONFIG_INET=y
CONFIG_NET_IPIP=y
CONFIG_INET_ECN=y
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
CONFIG_INET_IPCOMP=y
CONFIG_IPV6=y
CONFIG_INET6_AH=y
CONFIG_INET6_ESP=y
CONFIG_INET6_IPCOMP=y
CONFIG_IPV6_TUNNEL=y
CONFIG_NETFILTER=y
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
CONFIG_IPV6_SCTP__=y
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_HTB=y
CONFIG_NETDEVICES=y
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_NET_VENDOR_3COM=y
CONFIG_VORTEX=y
CONFIG_NET_RADIO=y
CONFIG_HOSTAP=y
CONFIG_HOSTAP_FIRMWARE=y
CONFIG_HOSTAP_CS=m
CONFIG_NET_WIRELESS=y
CONFIG_NET_PCMCIA=y
CONFIG_INPUT=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_EVDEV=y
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
CONFIG_INPUT_UINPUT=y
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_ACPI=y
CONFIG_SERIAL_CORE=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
CONFIG_PRINTER=y
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_PIIX4=y
CONFIG_I2C_SIS5595=y
CONFIG_I2C_SIS630=y
CONFIG_I2C_SENSOR=y
CONFIG_SENSORS_ADM1021=y
CONFIG_SENSORS_EEPROM=y
CONFIG_SENSORS_LM75=y
CONFIG_SENSORS_LM78=y
CONFIG_SENSORS_LM85=y
CONFIG_SENSORS_W83781D=y
CONFIG_HW_RANDOM=y
CONFIG_RTC=y
CONFIG_AGP=y
CONFIG_AGP_ATI=y
CONFIG_AGP_INTEL=y
CONFIG_DRM=y
CONFIG_DRM_R128=y
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_JBD=y
CONFIG_FS_MBCACHE=y
CONFIG_FS_POSIX_ACL=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_FAT_FS=m
CONFIG_VFAT_FS=m
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_DEVFS_FS=y
CONFIG_DEVFS_MOUNT=y
CONFIG_DEVPTS_FS=y
CONFIG_RAMFS=y
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_850=y
CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_15=y
CONFIG_NLS_UTF8=y
CONFIG_VIDEO_SELECT=y
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_SOUND=y
CONFIG_SND=y
CONFIG_SND_SEQUENCER=y
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=y
CONFIG_SND_MAESTRO3=y
CONFIG_USB=y
CONFIG_USB_DEVICEFS=y
CONFIG_USB_DYNAMIC_MINORS=y
CONFIG_USB_UHCI_HCD=y
CONFIG_USB_AUDIO=y
CONFIG_USB_PRINTER=y
CONFIG_USB_SCANNER=y
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_CAPABILITIES=y
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_BLOWFISH=y
CONFIG_CRYPTO_TWOFISH=y
CONFIG_CRYPTO_SERPENT=y
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_CAST5=y
CONFIG_CRYPTO_CAST6=y
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRC32=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_X86_BIOS_REBOOT=y


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28 11:05 ` Andreas Jellinghaus
@ 2003-09-28 12:34   ` Dave Jones
  2003-09-28 16:12     ` Andreas Jellinghaus
  0 siblings, 1 reply; 128+ messages in thread
From: Dave Jones @ 2003-09-28 12:34 UTC (permalink / raw)
  To: Andreas Jellinghaus; +Cc: linux-kernel

On Sun, Sep 28, 2003 at 01:05:35PM +0200, Andreas Jellinghaus wrote:
 > test6 (plus hostap patch) hangs during boot.
 > The last line I see is 
 > cpufreq: Intel(R) SpeedStep(TM) for this chip set not (yet) available.

Does it still hang if you disable the speedstep driver ?

 > and with test5 the next line would be:
 > IA-32 Microcode Update Driver: v1.11 <tigran@veritas.com>
 > 
 > booted with parameters:
 > kernel /vmlinuz-2.6.0-test6 root=/dev/hda2 ro hda=2432,255,63 resume=/dev/hda3
 > elevator=deadline psmouse_noext
 > 
 > but without the last three params it didn't change anything.

What happens if you don't pass the hda geometry ?
And, why do you need to ?

		Dave

-- 
 Dave Jones     http://www.codemonkey.org.uk

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28 12:34   ` Dave Jones
@ 2003-09-28 16:12     ` Andreas Jellinghaus
  2003-09-28 17:51       ` Andries Brouwer
  0 siblings, 1 reply; 128+ messages in thread
From: Andreas Jellinghaus @ 2003-09-28 16:12 UTC (permalink / raw)
  To: Dave Jones, linux-kernel

On So, 2003-09-28 at 14:34, Dave Jones wrote:
> On Sun, Sep 28, 2003 at 01:05:35PM +0200, Andreas Jellinghaus wrote:
>  > test6 (plus hostap patch) hangs during boot.
>  > The last line I see is 
>  > cpufreq: Intel(R) SpeedStep(TM) for this chip set not (yet) available.
> 
> Does it still hang if you disable the speedstep driver ?

# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
# CONFIG_X86_SPEEDSTEP_ICH is not set
# CONFIG_X86_SPEEDSTEP_SMI is not set
now it works fine.

> What happens if you don't pass the hda geometry ?
> And, why do you need to ?

the dell bios detects the disc as */16/63. However the
partition table is created with */255/63 in mind.
most bios allow to set the geometry manually or change
the large/lba/normal mode. the dell bios does not.

Linux boots fine without the hda= setting, as it only
uses start and length values. But other tools might have
problems (grub? *fdisk?).

Also I used to use drive image / dos version with network stack
for duplicating discs. and drive image only worked with win
and linux partitions, if the emulation geometry was */255/63.
Not sure why. But because of that all blank discs are created
with */255/63 tables. all other machines I know can be configured
via that large/lba/normale mode setting, or simply read the partition
table and automatically adjust to the geometry found.

Ah, live would be so much easier without chs geometries.

Is there any tool that will change chs begin/end values
from */255/63 geometry to */16/63 geometry? 

/dev/discs/disc0/part1 : start=       63, size=   112392, Id=83, b
/dev/discs/disc0/part2 : start=  2216970, size= 36853110, Id=83
/dev/discs/disc0/part3 : start=   112455, size=  2104515, Id=82

x/16/63 world:
0/1/1 - 111/8/63, 111/9/1 - 2199/5/63, 2199/6/1 - 38759/15/63

y/255/63 world:
0/1/1 - 6/254/63, 7/0/0 - 137/254/63, 138/0/1 - 2431/254/63

maybe there is still some software out there, that will not like
partitions beginning on something different then */0/1 or
*/1/1. I rather not change the partition table to */16/63
fake geometry.

I could backup everything, null the partition table, create a
new one with */16/63 chs geometry and restore all data. 
but for now using hda= to set the fake geometry works fine.

Regards, Andreas


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28  1:27 Linux 2.6.0-test6 Linus Torvalds
                   ` (4 preceding siblings ...)
  2003-09-28 11:05 ` Andreas Jellinghaus
@ 2003-09-28 16:42 ` Ivan Gyurdiev
  2003-09-28 20:26 ` [patch] 2.6.0-test6: correct hdlcdrv.h prototypes Adrian Bunk
                   ` (3 subsequent siblings)
  9 siblings, 0 replies; 128+ messages in thread
From: Ivan Gyurdiev @ 2003-09-28 16:42 UTC (permalink / raw)
  To: alsa-devel, Kernel Mailing List

This release broke ALSA for me. OSS emulation continued to work for 
xmms, but not for wine. The via_82xx driver told me to try 
dxs_support=1, so I did and it works again.

This is an ALC650-based:

00:11.5 Multimedia audio controller: VIA Technologies, Inc. 
VT8233/A/8235 AC97 Audio Controller (rev 50)

(I'm sorry if this is a second post to LKML - mailer problems)

> Jaroslav Kysela:
>   o ALSA CVS updates
>     - clean up the usage of the size variable and removes size1.
>     - define AD198x bits.
>     - add descriptions for whole-frag and no-silence commands.
>     - use dxs_support=3 (48k fixed) as default, since there are so many problems
>       with dxs_support=0.
>     - add the support for stereo mute switches on AD198x.
>     - initialize tumbler/snapper audio via gpio before i2c initialization.
>     - add check of DXS supports (so far, empty).
>     - add detection of revision of ALC650 chip
>     - get_page() fix
>     - fix the SPDIF bit on aureon boards.
>     - set 48k only for the sample rate of SPDIF on nForce.
>     - kill of not-required version.h inclusion
>     - Remove duplicated include
>     - fix buffer overlap on FX8010 PCM.
>     - Fix hwdep hotplug problem
>     - Use try_module_get() and module_put() to block the toplevel module
>     - Fix returned error code in the release() callback
>     etc
> 


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28 16:12     ` Andreas Jellinghaus
@ 2003-09-28 17:51       ` Andries Brouwer
  0 siblings, 0 replies; 128+ messages in thread
From: Andries Brouwer @ 2003-09-28 17:51 UTC (permalink / raw)
  To: Andreas Jellinghaus; +Cc: Dave Jones, linux-kernel

On Sun, Sep 28, 2003 at 06:12:26PM +0200, Andreas Jellinghaus wrote:

> Is there any tool that will change chs begin/end values
> from */255/63 geometry to */16/63 geometry? 

You could try sfdisk. Perhaps
	sfdisk -d /dev/hda > hda.pt
	sfdisk -H 16 -S 63 /dev/hda < hda.pt
will do the trick.
(Read the man page. Save your old table. Maybe -f is needed.)




^ permalink raw reply	[flat|nested] 128+ messages in thread

* [patch] 2.6.0-test6: correct hdlcdrv.h prototypes
  2003-09-28  1:27 Linux 2.6.0-test6 Linus Torvalds
                   ` (5 preceding siblings ...)
  2003-09-28 16:42 ` Ivan Gyurdiev
@ 2003-09-28 20:26 ` Adrian Bunk
  2003-09-29 13:23 ` Linux 2.6.0-test6 Florin Iucha
                   ` (2 subsequent siblings)
  9 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2003-09-28 20:26 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: Kernel Mailing List, linux-net, jgarzik, sailer

On Sat, Sep 27, 2003 at 06:27:35PM -0700, Linus Torvalds wrote:
>...
> Summary of changes from v2.6.0-test5 to v2.6.0-test6
> ============================================
>...
> Stephen Hemminger:
>...
>   o (1/4) Update baycom drivers for 2.6
>...

This patch changed two functions but not the corresponding prototypes in 
the header file resulting in some compile warnings.

The patch below updates hdlcdrv.h .

cu
Adrian

--- linux-2.6.0-test6-full/include/linux/hdlcdrv.h.old	2003-09-28 21:52:00.000000000 +0200
+++ linux-2.6.0-test6-full/include/linux/hdlcdrv.h	2003-09-28 22:16:37.000000000 +0200
@@ -359,11 +359,11 @@
 void hdlcdrv_receiver(struct net_device *, struct hdlcdrv_state *);
 void hdlcdrv_transmitter(struct net_device *, struct hdlcdrv_state *);
 void hdlcdrv_arbitrate(struct net_device *, struct hdlcdrv_state *);
-int hdlcdrv_register_hdlcdrv(struct net_device *dev, const struct hdlcdrv_ops *ops,
-			     unsigned int privsize, char *ifname,
+struct net_device *hdlcdrv_register(const struct hdlcdrv_ops *ops,
+			     unsigned int privsize, const char *ifname,
 			     unsigned int baseaddr, unsigned int irq, 
 			     unsigned int dma);
-int hdlcdrv_unregister_hdlcdrv(struct net_device *dev);
+void hdlcdrv_unregister(struct net_device *dev);
 
 /* -------------------------------------------------------------------- */
 

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28 10:02   ` Rob Landley
@ 2003-09-29  4:55     ` Nick Piggin
  2003-09-29  7:35       ` Rob Landley
                         ` (2 more replies)
  0 siblings, 3 replies; 128+ messages in thread
From: Nick Piggin @ 2003-09-29  4:55 UTC (permalink / raw)
  To: rob; +Cc: Con Kolivas, Kernel Mailing List



Rob Landley wrote:

>On Sunday 28 September 2003 02:03, Con Kolivas wrote:
>
>>On Sun, 28 Sep 2003 11:27, Linus Torvalds wrote:
>>
>>>from Andrew Morton. Most notably perhaps Con's scheduler changes that
>>>have been discussed extensively and made it into the -mm tree for
>>>testing.
>>>
>>For those who are trying this for the first time, please note that the
>>scheduler has been tuned to tell the difference between tasks of the _same_
>>nice level. This means do NOT renice X or it will make audio skip unless
>>you also renice your audio application by the same amount. Lots of
>>distributions have done this for the old 2.4 scheduler which could not
>>treat equal "nice" levels as differently as the new scheduler does and 2.6
>>shouldn't need special treatment.
>>
>>So for testing note the following points:
>>
>>Make sure X is NOT reniced to -10 as many distributions are doing.
>>Some shells spawn processes at nice +5 by default and this will make audio
>>apps suffer.
>>Make sure your hard disk, graphics card and audio card are performing at
>>equal standard to your 2.4 kernel (ie dma is working, graphics is fully
>>accelerated etc).
>>
>
>I.E. with your new scheduler, priority levels actually have enough of an 
>effect now that things that aren't reniced can be noticeably starved by 
>things that are.
>

AFAIK, Con's scheduler doesn't change the nice implementation at all.
Possibly some of his changes amplify its problems, or, more likely they
remove most other scheduler problems leaving this one noticable.

If X is running at -20, and xmms at +19, xmms is supposed to still get
5% of the CPU. Should be enough to run fine. Unfortunately this is
achieved by giving X very large timeslices, so xmms's scheduling latency
becomes large. The interactivity bonuses don't help, either.



^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-29  4:55     ` Nick Piggin
@ 2003-09-29  7:35       ` Rob Landley
  2003-09-29 16:55       ` Ed Sweetman
  2003-09-29 18:45       ` bill davidsen
  2 siblings, 0 replies; 128+ messages in thread
From: Rob Landley @ 2003-09-29  7:35 UTC (permalink / raw)
  To: Nick Piggin; +Cc: Con Kolivas, Kernel Mailing List

On Sunday 28 September 2003 23:55, Nick Piggin wrote:

> >I.E. with your new scheduler, priority levels actually have enough of an
> >effect now that things that aren't reniced can be noticeably starved by
> >things that are.
>
> AFAIK, Con's scheduler doesn't change the nice implementation at all.
> Possibly some of his changes amplify its problems, or, more likely they
> remove most other scheduler problems leaving this one noticable.
>
> If X is running at -20, and xmms at +19, xmms is supposed to still get
> 5% of the CPU. Should be enough to run fine. Unfortunately this is
> achieved by giving X very large timeslices, so xmms's scheduling latency
> becomes large. The interactivity bonuses don't help, either.

It's the old latency vs throughput problem.  Nice only has a single linear 
metric, it says you want more or you want less but it doesn't say more or 
less of _what_.

Rob

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28  1:27 Linux 2.6.0-test6 Linus Torvalds
                   ` (6 preceding siblings ...)
  2003-09-28 20:26 ` [patch] 2.6.0-test6: correct hdlcdrv.h prototypes Adrian Bunk
@ 2003-09-29 13:23 ` Florin Iucha
  2003-09-29 13:55   ` Muli Ben-Yehuda
  2003-09-29 13:58   ` Jaroslav Kysela
  2003-09-29 16:30 ` Linux 2.6.0-test6 (compile statistics) John Cherry
  2003-10-01  8:58 ` Who changed /proc/<pid>/ in 2.6.0-test5-bk9? Mikael Pettersson
  9 siblings, 2 replies; 128+ messages in thread
From: Florin Iucha @ 2003-09-29 13:23 UTC (permalink / raw)
  To: Jaroslav Kysela; +Cc: Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 576 bytes --]

On Sat, Sep 27, 2003 at 06:27:35PM -0700, Linus Torvalds wrote:
> 
[snip]
> arm, s390, ia64, x86-64, and ppc64 updates. USB, pcmcia and i2c stuff. And 
> a fair amount of janitorial.

I can no longer select my soundcard: In test5 it was configured by
CONFIG_SND_CS46XX! This option is no longer available in test6 (make
menuconfig does not offer me the opportunity).

It happened between test5-bk11 (option set/module build) and bk13
(option not available).

Please, give my sound option back!
florin

-- 

Don't question authority: they don't know either!

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-29 13:23 ` Linux 2.6.0-test6 Florin Iucha
@ 2003-09-29 13:55   ` Muli Ben-Yehuda
  2003-09-29 14:01     ` Jaroslav Kysela
  2003-09-29 13:58   ` Jaroslav Kysela
  1 sibling, 1 reply; 128+ messages in thread
From: Muli Ben-Yehuda @ 2003-09-29 13:55 UTC (permalink / raw)
  To: Florin Iucha, Jaroslav Kysela; +Cc: Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 2543 bytes --]

On Mon, Sep 29, 2003 at 08:23:55AM -0500, Florin Iucha wrote:

> I can no longer select my soundcard: In test5 it was configured by
> CONFIG_SND_CS46XX! This option is no longer available in test6 (make
> menuconfig does not offer me the opportunity).

You need to enable CONFIG_GAMEPORT, or apply this patch. Jaroslav, is
there a master plan for the CONFIG_SOUND_GAMEPORT -> CONFIG_GAMEPORT
conversion or is it a bug? this patch reverts it. 

diff -Naur --exclude-from /home/muli/p/dontdiff linux-2.5/sound/pci/Kconfig revert-alsa-gameport-2.6.0-t6/sound/pci/Kconfig
--- linux-2.5/sound/pci/Kconfig	Mon Sep 29 16:46:37 2003
+++ revert-alsa-gameport-2.6.0-t6/sound/pci/Kconfig	Mon Sep 29 16:48:00 2003
@@ -17,7 +17,7 @@
 
 config SND_CS46XX
 	tristate "Cirrus Logic (Sound Fusion) CS4280/CS461x/CS462x/CS463x"
-	depends on SND && GAMEPORT
+	depends on SND && SOUND_GAMEPORT
 	help
 	  Say 'Y' or 'M' to include support for Cirrus Logic CS4610 / CS4612 /
 	  CS4614 / CS4615 / CS4622 / CS4624 / CS4630 / CS4280 chips.
@@ -30,7 +30,7 @@
 
 config SND_CS4281
 	tristate "Cirrus Logic (Sound Fusion) CS4281"
-	depends on SND && GAMEPORT
+	depends on SND && SOUND_GAMEPORT
 	help
 	  Say 'Y' or 'M' to include support for Cirrus Logic CS4281.
 
@@ -83,7 +83,7 @@
 
 config SND_TRIDENT
 	tristate "Trident 4D-Wave DX/NX; SiS 7018"
-	depends on SND && GAMEPORT
+	depends on SND && SOUND_GAMEPORT
 	help
 	  Say 'Y' or 'M' to include support for Trident 4D-Wave DX/NX and
 	  SiS 7018 soundcards.
@@ -110,20 +110,20 @@
 
 config SND_ENS1370
 	tristate "(Creative) Ensoniq AudioPCI 1370"
-	depends on SND && GAMEPORT
+	depends on SND && SOUND_GAMEPORT
 	help
 	  Say 'Y' or 'M' to include support for Ensoniq AudioPCI ES1370.
 
 config SND_ENS1371
 	tristate "(Creative) Ensoniq AudioPCI 1371/1373"
-	depends on SND && GAMEPORT
+	depends on SND && SOUND_GAMEPORT
 	help
 	  Say 'Y' or 'M' to include support for Ensoniq AudioPCI ES1371 and
 	  Sound Blaster PCI 64 or 128 soundcards.
 
 config SND_ES1938
 	tristate "ESS ES1938/1946/1969 (Solo-1)"
-	depends on SND && GAMEPORT
+	depends on SND && SOUND_GAMEPORT
 	help
 	  Say 'Y' or 'M' to include support for ESS Solo-1 (ES1938, ES1946, ES1969)
 	  soundcard.
@@ -173,7 +173,7 @@
 
 config SND_SONICVIBES
 	tristate "S3 SonicVibes"
-	depends on SND && GAMEPORT
+	depends on SND && SOUND_GAMEPORT
 	help
 	  Say 'Y' or 'M' to include support for S3 SonicVibes based soundcards.
 

-- 
Muli Ben-Yehuda
http://www.mulix.org


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-29 13:23 ` Linux 2.6.0-test6 Florin Iucha
  2003-09-29 13:55   ` Muli Ben-Yehuda
@ 2003-09-29 13:58   ` Jaroslav Kysela
  1 sibling, 0 replies; 128+ messages in thread
From: Jaroslav Kysela @ 2003-09-29 13:58 UTC (permalink / raw)
  To: Florin Iucha; +Cc: Kernel Mailing List

On Mon, 29 Sep 2003, Florin Iucha wrote:

> On Sat, Sep 27, 2003 at 06:27:35PM -0700, Linus Torvalds wrote:
> >
> [snip]
> > arm, s390, ia64, x86-64, and ppc64 updates. USB, pcmcia and i2c stuff. And
> > a fair amount of janitorial.
>
> I can no longer select my soundcard: In test5 it was configured by
> CONFIG_SND_CS46XX! This option is no longer available in test6 (make
> menuconfig does not offer me the opportunity).
>
> It happened between test5-bk11 (option set/module build) and bk13
> (option not available).
>
> Please, give my sound option back!

The driver is still there. As workaround, you can enable GAMEPORT or kill
all occurences of string '&& GAMEPORT' in sound/pci/Kconfig (it's the real
fix).

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-29 13:55   ` Muli Ben-Yehuda
@ 2003-09-29 14:01     ` Jaroslav Kysela
  2003-09-29 14:18       ` Muli Ben-Yehuda
  2003-09-29 14:30       ` Takashi Iwai
  0 siblings, 2 replies; 128+ messages in thread
From: Jaroslav Kysela @ 2003-09-29 14:01 UTC (permalink / raw)
  To: Muli Ben-Yehuda; +Cc: Florin Iucha, Kernel Mailing List

On Mon, 29 Sep 2003, Muli Ben-Yehuda wrote:

> On Mon, Sep 29, 2003 at 08:23:55AM -0500, Florin Iucha wrote:
>
> > I can no longer select my soundcard: In test5 it was configured by
> > CONFIG_SND_CS46XX! This option is no longer available in test6 (make
> > menuconfig does not offer me the opportunity).
>
> You need to enable CONFIG_GAMEPORT, or apply this patch. Jaroslav, is
> there a master plan for the CONFIG_SOUND_GAMEPORT -> CONFIG_GAMEPORT
> conversion or is it a bug? this patch reverts it.

CONFIG_SOUND_GAMEPORT define is ugly. It's better to remove all gameport
dependencies from the ALSA's configuration files and let drivers to
detect the gameport presence at "compile" time.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-29 14:01     ` Jaroslav Kysela
@ 2003-09-29 14:18       ` Muli Ben-Yehuda
  2003-09-29 19:04         ` bill davidsen
  2003-09-29 14:30       ` Takashi Iwai
  1 sibling, 1 reply; 128+ messages in thread
From: Muli Ben-Yehuda @ 2003-09-29 14:18 UTC (permalink / raw)
  To: Jaroslav Kysela; +Cc: Florin Iucha, Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 3061 bytes --]

On Mon, Sep 29, 2003 at 04:01:09PM +0200, Jaroslav Kysela wrote:
> On Mon, 29 Sep 2003, Muli Ben-Yehuda wrote:
> 
> > On Mon, Sep 29, 2003 at 08:23:55AM -0500, Florin Iucha wrote:
> >
> > > I can no longer select my soundcard: In test5 it was configured by
> > > CONFIG_SND_CS46XX! This option is no longer available in test6 (make
> > > menuconfig does not offer me the opportunity).
> >
> > You need to enable CONFIG_GAMEPORT, or apply this patch. Jaroslav, is
> > there a master plan for the CONFIG_SOUND_GAMEPORT -> CONFIG_GAMEPORT
> > conversion or is it a bug? this patch reverts it.
> 
> CONFIG_SOUND_GAMEPORT define is ugly. It's better to remove all gameport
> dependencies from the ALSA's configuration files and let drivers to
> detect the gameport presence at "compile" time.

I think it's a build system issue and thus should be handled by the
build system, not by #ifdefs. However, if that's the way you prefer
it, here's a patch to remove the GAMEPORT dependencies from
sound/pci/Kconfig. From a quick glance, all affected drivers have the
necessary ifdefs. 

diff -Naur --exclude-from /home/muli/p/dontdiff linux-2.5/sound/pci/Kconfig revert-alsa-gameport-2.6.0-t6/sound/pci/Kconfig
--- linux-2.5/sound/pci/Kconfig	Mon Sep 29 16:46:37 2003
+++ revert-alsa-gameport-2.6.0-t6/sound/pci/Kconfig	Mon Sep 29 17:14:36 2003
@@ -17,7 +17,7 @@
 
 config SND_CS46XX
 	tristate "Cirrus Logic (Sound Fusion) CS4280/CS461x/CS462x/CS463x"
-	depends on SND && GAMEPORT
+	depends on SND
 	help
 	  Say 'Y' or 'M' to include support for Cirrus Logic CS4610 / CS4612 /
 	  CS4614 / CS4615 / CS4622 / CS4624 / CS4630 / CS4280 chips.
@@ -30,7 +30,7 @@
 
 config SND_CS4281
 	tristate "Cirrus Logic (Sound Fusion) CS4281"
-	depends on SND && GAMEPORT
+	depends on SND
 	help
 	  Say 'Y' or 'M' to include support for Cirrus Logic CS4281.
 
@@ -83,7 +83,7 @@
 
 config SND_TRIDENT
 	tristate "Trident 4D-Wave DX/NX; SiS 7018"
-	depends on SND && GAMEPORT
+	depends on SND
 	help
 	  Say 'Y' or 'M' to include support for Trident 4D-Wave DX/NX and
 	  SiS 7018 soundcards.
@@ -110,20 +110,20 @@
 
 config SND_ENS1370
 	tristate "(Creative) Ensoniq AudioPCI 1370"
-	depends on SND && GAMEPORT
+	depends on SND
 	help
 	  Say 'Y' or 'M' to include support for Ensoniq AudioPCI ES1370.
 
 config SND_ENS1371
 	tristate "(Creative) Ensoniq AudioPCI 1371/1373"
-	depends on SND && GAMEPORT
+	depends on SND
 	help
 	  Say 'Y' or 'M' to include support for Ensoniq AudioPCI ES1371 and
 	  Sound Blaster PCI 64 or 128 soundcards.
 
 config SND_ES1938
 	tristate "ESS ES1938/1946/1969 (Solo-1)"
-	depends on SND && GAMEPORT
+	depends on SND
 	help
 	  Say 'Y' or 'M' to include support for ESS Solo-1 (ES1938, ES1946, ES1969)
 	  soundcard.
@@ -173,7 +173,7 @@
 
 config SND_SONICVIBES
 	tristate "S3 SonicVibes"
-	depends on SND && GAMEPORT
+	depends on SND
 	help
 	  Say 'Y' or 'M' to include support for S3 SonicVibes based soundcards.
 

-- 
Muli Ben-Yehuda
http://www.mulix.org


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-29 14:01     ` Jaroslav Kysela
  2003-09-29 14:18       ` Muli Ben-Yehuda
@ 2003-09-29 14:30       ` Takashi Iwai
  1 sibling, 0 replies; 128+ messages in thread
From: Takashi Iwai @ 2003-09-29 14:30 UTC (permalink / raw)
  To: Jaroslav Kysela; +Cc: Muli Ben-Yehuda, Florin Iucha, Kernel Mailing List

At Mon, 29 Sep 2003 16:01:09 +0200 (CEST),
Jaroslav wrote:
> 
> On Mon, 29 Sep 2003, Muli Ben-Yehuda wrote:
> 
> > On Mon, Sep 29, 2003 at 08:23:55AM -0500, Florin Iucha wrote:
> >
> > > I can no longer select my soundcard: In test5 it was configured by
> > > CONFIG_SND_CS46XX! This option is no longer available in test6 (make
> > > menuconfig does not offer me the opportunity).
> >
> > You need to enable CONFIG_GAMEPORT, or apply this patch. Jaroslav, is
> > there a master plan for the CONFIG_SOUND_GAMEPORT -> CONFIG_GAMEPORT
> > conversion or is it a bug? this patch reverts it.
> 
> CONFIG_SOUND_GAMEPORT define is ugly. It's better to remove all gameport
> dependencies from the ALSA's configuration files and let drivers to
> detect the gameport presence at "compile" time.

well, as Muli pointed out in another thread, the problem is when
ALSA=y but GAMEPORT=m.  and, in such a case, there is a difference
between with and without CONFIG_SOUND_GAMEPORT condition.

if CONFIG_SOUND_GAMEPORT is used, the ALSA module will be forced to be
m, so that the gameport is supported.
if we drop this condition check, the ALSA will be kept as y, and the
gameport support will be simply dropped, too.

i think it would be better if we can show warnings about this
confliction instead of dropping the functionality silently.
but if there is no way.... hmm, difficult to say which is better
behavior.


--
Takashi Iwai <tiwai dot suse.de>		ALSA Developer - www.alsa-project.org

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: keyboard repeat / sound [was Re: Linux 2.6.0-test6]
  2003-09-28  8:59 ` keyboard repeat / sound [was Re: Linux 2.6.0-test6] Roger Luethi
@ 2003-09-29 15:16   ` Vojtech Pavlik
  2003-09-30  7:50     ` Paul
  0 siblings, 1 reply; 128+ messages in thread
From: Vojtech Pavlik @ 2003-09-29 15:16 UTC (permalink / raw)
  To: Kernel Mailing List

On Sun, Sep 28, 2003 at 10:59:02AM +0200, Roger Luethi wrote:

> With test6, keyboard repeat takes very noticably longer to kick in after X
> has been started (for both X and console). In test5, starting X makes no
> difference.

Bug in repeat rate setting code. Thanks for reporting, this should fix
it:

diff -Nru a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
--- a/drivers/input/keyboard/atkbd.c	Mon Sep 29 17:16:17 2003
+++ b/drivers/input/keyboard/atkbd.c	Mon Sep 29 17:16:17 2003
@@ -370,10 +370,11 @@
 static int atkbd_event(struct input_dev *dev, unsigned int type, unsigned int code, int value)
 {
 	struct atkbd *atkbd = dev->private;
-	struct { int p; u8 v; } period[] =	
-		{ {30, 0x00}, {25, 0x02}, {20, 0x04}, {15, 0x08}, {10, 0x0c}, {7, 0x10}, {5, 0x14}, {0, 0x14} };
-	struct { int d; u8 v; } delay[] =
-        	{ {1000, 0x60}, {750, 0x40}, {500, 0x20}, {250, 0x00}, {0, 0x00} };
+	const short period[32] =
+		{ 33,  37,  42,  46,  50,  54,  58,  63,  67,  75,  83,  92, 100, 109, 116, 125,
+		 133, 149, 167, 182, 200, 217, 232, 250, 270, 303, 333, 370, 400, 435, 470, 500 };
+	const short delay[4] =
+		{ 250, 500, 750, 1000 };
 	char param[2];
 	int i, j;
 
@@ -407,11 +408,11 @@
 			if (atkbd_softrepeat) return 0;
 
 			i = j = 0;
-			while (period[i].p > dev->rep[REP_PERIOD]) i++;
-			while (delay[j].d > dev->rep[REP_DELAY]) j++;
-			dev->rep[REP_PERIOD] = period[i].p;
-			dev->rep[REP_DELAY] = delay[j].d;
-			param[0] = period[i].v | delay[j].v;
+			while (i < 32 && period[i] < dev->rep[REP_PERIOD]) i++;
+			while (j < 4 && delay[j] < dev->rep[REP_DELAY]) j++;
+			dev->rep[REP_PERIOD] = period[i];
+			dev->rep[REP_DELAY] = delay[j];
+			param[0] = i | (j << 5);
 			atkbd_command(atkbd, param, ATKBD_CMD_SETREP);
 
 			return 0;

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6 (compile statistics)
  2003-09-28  1:27 Linux 2.6.0-test6 Linus Torvalds
                   ` (7 preceding siblings ...)
  2003-09-29 13:23 ` Linux 2.6.0-test6 Florin Iucha
@ 2003-09-29 16:30 ` John Cherry
  2003-09-29 17:44   ` Jesper Juhl
  2003-10-01  8:58 ` Who changed /proc/<pid>/ in 2.6.0-test5-bk9? Mikael Pettersson
  9 siblings, 1 reply; 128+ messages in thread
From: John Cherry @ 2003-09-29 16:30 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Kernel Mailing List

Linux 2.6 Compile Statistics (gcc 3.2.2)
----------------------------------------

Warnings/Errors Summary

Kernel         bzImage    bzImage  modules  bzImage   modules
             (defconfig)  (allyes) (allyes) (allmod) (allmod)
-----------  -----------  -------- -------- -------- ---------
2.6.0-test6    0w/0e      188w/ 1e  12w/0e   3w/0e    260w/ 2e
2.6.0-test5    0w/0e      205w/ 9e  15w/1e   0w/0e    305w/ 5e
2.6.0-test4    0w/0e      797w/55e  68w/1e   3w/0e   1016w/34e
2.6.0-test3    0w/0e      755w/66e  62w/1e   7w/9e    984w/42e
2.6.0-test2    0w/0e      952w/65e  63w/2e   7w/9e   1201w/43e
2.6.0-test1    0w/0e     1016w/60e  75w/1e   8w/9e   1319w/38e

Web page with links to complete details:
   http://developer.osdl.org/cherry/compile/
Daily compiles (ia32): 
   http://developer.osdl.org/cherry/compile/2.6/linus-tree/running.txt
Daily compiles (ia64): 
   http://developer.osdl.org/cherry/compile/2.6/linus-tree/running64.txt
Latest changes in Linus' bitkeeper tree:
   http://linux.bkbits.net:8080/linux-2.5

Warning Summary
   drivers/block: 1 warnings, 0 errors
   drivers/cdrom: 3 warnings, 0 errors
   drivers/char: 2 warnings, 0 errors
   drivers/ide: 30 warnings, 0 errors
   drivers/media: 5 warnings, 0 errors
   drivers/message: 1 warnings, 0 errors
   drivers/mtd: 25 warnings, 0 errors
   drivers/pcmcia: 3 warnings, 0 errors
   drivers/scsi/pcmcia: 4 warnings, 0 errors
   drivers/scsi: 43 warnings, 0 errors
   drivers/serial: 1 warnings, 0 errors
   drivers/telephony: 5 warnings, 0 errors
   drivers/video/aty: 3 warnings, 0 errors
   drivers/video/console: 2 warnings, 0 errors
   drivers/video/matrox: 5 warnings, 0 errors
   drivers/video/sis: 1 warnings, 0 errors
   drivers/video: 8 warnings, 0 errors
   net: 13 warnings, 0 errors
   sound/isa: 3 warnings, 0 errors
   sound/oss: 49 warnings, 0 errors

Error Summary

   drivers/net: 0 warnings, 3 errors
   drivers/net: 57 warnings, 2 errors

John





^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-29  4:55     ` Nick Piggin
  2003-09-29  7:35       ` Rob Landley
@ 2003-09-29 16:55       ` Ed Sweetman
  2003-09-30  0:03         ` Nick Piggin
  2003-10-02  0:41         ` Pedro Larroy
  2003-09-29 18:45       ` bill davidsen
  2 siblings, 2 replies; 128+ messages in thread
From: Ed Sweetman @ 2003-09-29 16:55 UTC (permalink / raw)
  To: Nick Piggin; +Cc: linux-kernel

Nick Piggin wrote:
> 
> 
> Rob Landley wrote:
> 
>> On Sunday 28 September 2003 02:03, Con Kolivas wrote:
>>
>>> On Sun, 28 Sep 2003 11:27, Linus Torvalds wrote:
>>>
>>>> from Andrew Morton. Most notably perhaps Con's scheduler changes that
>>>> have been discussed extensively and made it into the -mm tree for
>>>> testing.
>>>>
>>> For those who are trying this for the first time, please note that the
>>> scheduler has been tuned to tell the difference between tasks of the 
>>> _same_
>>> nice level. This means do NOT renice X or it will make audio skip unless
>>> you also renice your audio application by the same amount. Lots of
>>> distributions have done this for the old 2.4 scheduler which could not
>>> treat equal "nice" levels as differently as the new scheduler does 
>>> and 2.6
>>> shouldn't need special treatment.
>>>
>>> So for testing note the following points:
>>>
>>> Make sure X is NOT reniced to -10 as many distributions are doing.
>>> Some shells spawn processes at nice +5 by default and this will make 
>>> audio
>>> apps suffer.
>>> Make sure your hard disk, graphics card and audio card are performing at
>>> equal standard to your 2.4 kernel (ie dma is working, graphics is fully
>>> accelerated etc).
>>>
>>
>> I.E. with your new scheduler, priority levels actually have enough of 
>> an effect now that things that aren't reniced can be noticeably 
>> starved by things that are.
>>
> 
> AFAIK, Con's scheduler doesn't change the nice implementation at all.
> Possibly some of his changes amplify its problems, or, more likely they
> remove most other scheduler problems leaving this one noticable.
> 
> If X is running at -20, and xmms at +19, xmms is supposed to still get
> 5% of the CPU. Should be enough to run fine. Unfortunately this is
> achieved by giving X very large timeslices, so xmms's scheduling latency
> becomes large. The interactivity bonuses don't help, either.
>

there are 40 positions between -20 and 19, that doesn't equal 5% steps. 
They don't even refer to % of cpu.  If i nice a process to -20 it 
doesn't get a given percentage of cpu just because it's -20. I may have 
other processes at -20 as well.  If you nice something to -20 and it is 
actually using that cpu then things that are +19 shouldn't run and wont 
run.  If I nice -20 vmstat 1, it's not going to starve xmms (or any 
better audio player).  -20 means starve all and it should do that when 
it actually makes use of the resources.




^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6 (compile statistics)
  2003-09-29 16:30 ` Linux 2.6.0-test6 (compile statistics) John Cherry
@ 2003-09-29 17:44   ` Jesper Juhl
  2003-10-06 20:39     ` John Cherry
  0 siblings, 1 reply; 128+ messages in thread
From: Jesper Juhl @ 2003-09-29 17:44 UTC (permalink / raw)
  To: John Cherry; +Cc: Linus Torvalds, Kernel Mailing List


On Mon, 29 Sep 2003, John Cherry wrote:

> Linux 2.6 Compile Statistics (gcc 3.2.2)
> ----------------------------------------
>
> Warnings/Errors Summary
>
> Kernel         bzImage    bzImage  modules  bzImage   modules
>              (defconfig)  (allyes) (allyes) (allmod) (allmod)
> -----------  -----------  -------- -------- -------- ---------
> 2.6.0-test6    0w/0e      188w/ 1e  12w/0e   3w/0e    260w/ 2e
> 2.6.0-test5    0w/0e      205w/ 9e  15w/1e   0w/0e    305w/ 5e
> 2.6.0-test4    0w/0e      797w/55e  68w/1e   3w/0e   1016w/34e
> 2.6.0-test3    0w/0e      755w/66e  62w/1e   7w/9e    984w/42e
> 2.6.0-test2    0w/0e      952w/65e  63w/2e   7w/9e   1201w/43e
> 2.6.0-test1    0w/0e     1016w/60e  75w/1e   8w/9e   1319w/38e
>

I was wondering if there would be any point in doing these builds with
"allnoconfig" as well?
Could this possibly flush out some warnings/errors that only occur when
something is left out?


/Jesper Juhl


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-29  4:55     ` Nick Piggin
  2003-09-29  7:35       ` Rob Landley
  2003-09-29 16:55       ` Ed Sweetman
@ 2003-09-29 18:45       ` bill davidsen
  2003-09-30  1:12         ` Nick Piggin
  2 siblings, 1 reply; 128+ messages in thread
From: bill davidsen @ 2003-09-29 18:45 UTC (permalink / raw)
  To: linux-kernel

In article <3F77BB2C.7030402@cyberone.com.au>,
Nick Piggin  <piggin@cyberone.com.au> wrote:

| AFAIK, Con's scheduler doesn't change the nice implementation at all.
| Possibly some of his changes amplify its problems, or, more likely they
| remove most other scheduler problems leaving this one noticable.
| 
| If X is running at -20, and xmms at +19, xmms is supposed to still get
| 5% of the CPU. Should be enough to run fine. Unfortunately this is
| achieved by giving X very large timeslices, so xmms's scheduling latency
| becomes large. The interactivity bonuses don't help, either.

Clearly the "some is good, more is better" approach doesn't provide
stable balance between sound and cpu hogs. It isn't a question of "how
much" cpu, just "when"which works or not.

This is sort of like the deadline scheduler in that it trades of
throughput for avoiding jackpot cases. I think that's desired behaviour
in a CPU schedular too, at least if used by humans.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-29 14:18       ` Muli Ben-Yehuda
@ 2003-09-29 19:04         ` bill davidsen
  0 siblings, 0 replies; 128+ messages in thread
From: bill davidsen @ 2003-09-29 19:04 UTC (permalink / raw)
  To: linux-kernel

In article <20030929141800.GP29313@actcom.co.il>,
Muli Ben-Yehuda  <mulix@mulix.org> wrote:

| I think it's a build system issue and thus should be handled by the
| build system, not by #ifdefs. However, if that's the way you prefer
| it, here's a patch to remove the GAMEPORT dependencies from
| sound/pci/Kconfig. From a quick glance, all affected drivers have the
| necessary ifdefs.=20

Yes, I think there are people who would like working sounds who don't
play games. It's totally inobvious that you need to configure gameport
support to get sound on the menu.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-29 16:55       ` Ed Sweetman
@ 2003-09-30  0:03         ` Nick Piggin
  2003-10-02  0:41         ` Pedro Larroy
  1 sibling, 0 replies; 128+ messages in thread
From: Nick Piggin @ 2003-09-30  0:03 UTC (permalink / raw)
  To: Ed Sweetman; +Cc: linux-kernel



Ed Sweetman wrote:

> Nick Piggin wrote:
>
>>
>>
>> Rob Landley wrote:
>>
>>> On Sunday 28 September 2003 02:03, Con Kolivas wrote:
>>>
>>>> On Sun, 28 Sep 2003 11:27, Linus Torvalds wrote:
>>>>
>>>>> from Andrew Morton. Most notably perhaps Con's scheduler changes that
>>>>> have been discussed extensively and made it into the -mm tree for
>>>>> testing.
>>>>>
>>>> For those who are trying this for the first time, please note that the
>>>> scheduler has been tuned to tell the difference between tasks of 
>>>> the _same_
>>>> nice level. This means do NOT renice X or it will make audio skip 
>>>> unless
>>>> you also renice your audio application by the same amount. Lots of
>>>> distributions have done this for the old 2.4 scheduler which could not
>>>> treat equal "nice" levels as differently as the new scheduler does 
>>>> and 2.6
>>>> shouldn't need special treatment.
>>>>
>>>> So for testing note the following points:
>>>>
>>>> Make sure X is NOT reniced to -10 as many distributions are doing.
>>>> Some shells spawn processes at nice +5 by default and this will 
>>>> make audio
>>>> apps suffer.
>>>> Make sure your hard disk, graphics card and audio card are 
>>>> performing at
>>>> equal standard to your 2.4 kernel (ie dma is working, graphics is 
>>>> fully
>>>> accelerated etc).
>>>>
>>>
>>> I.E. with your new scheduler, priority levels actually have enough 
>>> of an effect now that things that aren't reniced can be noticeably 
>>> starved by things that are.
>>>
>>
>> AFAIK, Con's scheduler doesn't change the nice implementation at all.
>> Possibly some of his changes amplify its problems, or, more likely they
>> remove most other scheduler problems leaving this one noticable.
>>
>> If X is running at -20, and xmms at +19, xmms is supposed to still get
>> 5% of the CPU. Should be enough to run fine. Unfortunately this is
>> achieved by giving X very large timeslices, so xmms's scheduling latency
>> becomes large. The interactivity bonuses don't help, either.
>>
>
> there are 40 positions between -20 and 19, that doesn't equal 5% 
> steps. They


No, but the maximum timeslice (sole metric changed by nice) is 200, the
min is 10 (5%). And between them, timeslices are calculated linearly.

> don't even refer to % of cpu.  If i nice a process to -20 it doesn't 
> get a given percentage of cpu just because it's -20. I may have other


No, but it should get 2000% of what a nice +19 process will get in the
same system (regardless of what else is running).

> processes at -20 as well.  If you nice something to -20 and it is 
> actually using that cpu then things that are +19 shouldn't run and


They do.

> wont run.  If I nice -20 vmstat 1, it's not going to starve xmms (or 
> any better audio player).  -20 means starve all and it should do that 
> when it actually makes use of the resources. 


I don't know exactly what nice is supposed to do other than "raise
priority", but its fairly well accepted that it should increase the
process' % cpu time (vs others) without completely starving everyone.

It is probably a justified criticism that 5% is too much for a +19 task
to get vs a -20 task, but it has to get something.


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-29 18:45       ` bill davidsen
@ 2003-09-30  1:12         ` Nick Piggin
  2003-10-01 21:13           ` bill davidsen
  0 siblings, 1 reply; 128+ messages in thread
From: Nick Piggin @ 2003-09-30  1:12 UTC (permalink / raw)
  To: bill davidsen; +Cc: linux-kernel



bill davidsen wrote:

>In article <3F77BB2C.7030402@cyberone.com.au>,
>Nick Piggin  <piggin@cyberone.com.au> wrote:
>
>| AFAIK, Con's scheduler doesn't change the nice implementation at all.
>| Possibly some of his changes amplify its problems, or, more likely they
>| remove most other scheduler problems leaving this one noticable.
>| 
>| If X is running at -20, and xmms at +19, xmms is supposed to still get
>| 5% of the CPU. Should be enough to run fine. Unfortunately this is
>| achieved by giving X very large timeslices, so xmms's scheduling latency
>| becomes large. The interactivity bonuses don't help, either.
>
>Clearly the "some is good, more is better" approach doesn't provide
>stable balance between sound and cpu hogs. It isn't a question of "how
>much" cpu, just "when"which works or not.
>
>This is sort of like the deadline scheduler in that it trades of
>throughput for avoiding jackpot cases. I think that's desired behaviour
>in a CPU schedular too, at least if used by humans.
>

I'm not sure what you mean. There is nothing good to say about Ingo's
nice mechanism though (sorry Ingo, its otherwise a very nice
scheduler!).

In my scheduler, nice -20 processes get small timeslices so scheduling
latency stays low or even gets lower, while nice +19 ones get large
timeslices for lower context switches and better cache efficiency. As
you would like.



^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: keyboard repeat / sound [was Re: Linux 2.6.0-test6]
  2003-09-29 15:16   ` Vojtech Pavlik
@ 2003-09-30  7:50     ` Paul
  2003-09-30 12:51       ` Vojtech Pavlik
  0 siblings, 1 reply; 128+ messages in thread
From: Paul @ 2003-09-30  7:50 UTC (permalink / raw)
  To: Vojtech Pavlik; +Cc: Kernel Mailing List

Vojtech Pavlik <vojtech@suse.cz>, on Mon Sep 29, 2003 [05:16:43 PM] said:
> On Sun, Sep 28, 2003 at 10:59:02AM +0200, Roger Luethi wrote:
> 
> > With test6, keyboard repeat takes very noticably longer to kick in after X
> > has been started (for both X and console). In test5, starting X makes no
> > difference.
> 
> Bug in repeat rate setting code. Thanks for reporting, this should fix
> it:
> 
	Hi;

	I applied this patch to 2.6.0-test6, but the delay before
repeat kicks in is slower than previous versions. It seems more like
the latest 2.4 kernel. Note, this isnt the speed of the repeat, but
the delay before it kicks in. Havent tested unpatched test6.
	On the other hand, the mouse pointer (ps/2) has been kicked
into overdrive. much faster than test5 and latest 2.4.
	Also, I think that the requirement to enable gameport in
the input section to get access to some alsa sound drivers is
a bug. Ive looked at the source to some, and they #ifdef around
gameport support. test5 didnt have this problem for my 1371 driver.

Paul
set@pobox.com
	

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: keyboard repeat / sound [was Re: Linux 2.6.0-test6]
  2003-09-30  7:50     ` Paul
@ 2003-09-30 12:51       ` Vojtech Pavlik
  2003-09-30 13:21         ` Aristeu Sergio Rozanski Filho
  0 siblings, 1 reply; 128+ messages in thread
From: Vojtech Pavlik @ 2003-09-30 12:51 UTC (permalink / raw)
  To: Paul, Vojtech Pavlik, Kernel Mailing List

On Tue, Sep 30, 2003 at 03:50:24AM -0400, Paul wrote:
> Vojtech Pavlik <vojtech@suse.cz>, on Mon Sep 29, 2003 [05:16:43 PM] said:
> > On Sun, Sep 28, 2003 at 10:59:02AM +0200, Roger Luethi wrote:
> > 
> > > With test6, keyboard repeat takes very noticably longer to kick in after X
> > > has been started (for both X and console). In test5, starting X makes no
> > > difference.
> > 
> > Bug in repeat rate setting code. Thanks for reporting, this should fix
> > it:
> > 
> 	Hi;
> 
> 	I applied this patch to 2.6.0-test6, but the delay before
> repeat kicks in is slower than previous versions. It seems more like
> the latest 2.4 kernel.

This is because it is the same as on the latest 2.4 kernel. 2.6 used
software autorepeat up to test6. Now, because of hardware bugs, it was
necessary to switch back to hardware autorepeat, like 2.4 uses.

> Note, this isnt the speed of the repeat, but
> the delay before it kicks in. Havent tested unpatched test6.
> 	On the other hand, the mouse pointer (ps/2) has been kicked
> into overdrive. much faster than test5 and latest 2.4.

Interesting. This probably has much to do with mouse acceleration
settings. What was done was that the mouse report rate was made LOWER
(60 compared to 200) to cure problems with some systems that couldn't
handle the high report rate.

This makes the movement per report larger and thus the acceleration
formula in XFree then works more aggressively.

> 	Also, I think that the requirement to enable gameport in
> the input section to get access to some alsa sound drivers is
> a bug. Ive looked at the source to some, and they #ifdef around
> gameport support. test5 didnt have this problem for my 1371 driver.

That one is for ALSA people.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: keyboard repeat / sound [was Re: Linux 2.6.0-test6]
  2003-09-30 12:51       ` Vojtech Pavlik
@ 2003-09-30 13:21         ` Aristeu Sergio Rozanski Filho
  2003-09-30 13:44           ` Vojtech Pavlik
  0 siblings, 1 reply; 128+ messages in thread
From: Aristeu Sergio Rozanski Filho @ 2003-09-30 13:21 UTC (permalink / raw)
  To: Vojtech Pavlik; +Cc: Kernel Mailing List

> This is because it is the same as on the latest 2.4 kernel. 2.6 used
> software autorepeat up to test6. Now, because of hardware bugs, it was
> necessary to switch back to hardware autorepeat, like 2.4 uses.
and it fixes the problem with my notebook's keyboard, thanks :)

> Interesting. This probably has much to do with mouse acceleration
> settings. What was done was that the mouse report rate was made LOWER
> (60 compared to 200) to cure problems with some systems that couldn't
> handle the high report rate.
> 
> This makes the movement per report larger and thus the acceleration
> formula in XFree then works more aggressively.
test6 was the first 2.5/2.6 kernel that psmouse_noext=1 wasn't necessary
to make my synaptics touchpad work. but i noticed it's much more
sensible (with leads to be very difficult to hit xmms' pause button :)
than using it with noext option. is anyone working in an user level
application to configure 2.6's synaptics touchpad driver?

thanks again for your effort

--
aris


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: keyboard repeat / sound [was Re: Linux 2.6.0-test6]
  2003-09-30 13:21         ` Aristeu Sergio Rozanski Filho
@ 2003-09-30 13:44           ` Vojtech Pavlik
  2003-09-30 14:05             ` Aristeu Sergio Rozanski Filho
  0 siblings, 1 reply; 128+ messages in thread
From: Vojtech Pavlik @ 2003-09-30 13:44 UTC (permalink / raw)
  To: Aristeu Sergio Rozanski Filho; +Cc: Vojtech Pavlik, Kernel Mailing List

On Tue, Sep 30, 2003 at 10:21:34AM -0300, Aristeu Sergio Rozanski Filho wrote:

> > This is because it is the same as on the latest 2.4 kernel. 2.6 used
> > software autorepeat up to test6. Now, because of hardware bugs, it was
> > necessary to switch back to hardware autorepeat, like 2.4 uses.
> and it fixes the problem with my notebook's keyboard, thanks :)

What problem exactly was that?

> > Interesting. This probably has much to do with mouse acceleration
> > settings. What was done was that the mouse report rate was made LOWER
> > (60 compared to 200) to cure problems with some systems that couldn't
> > handle the high report rate.
> > 
> > This makes the movement per report larger and thus the acceleration
> > formula in XFree then works more aggressively.

> test6 was the first 2.5/2.6 kernel that psmouse_noext=1 wasn't necessary
> to make my synaptics touchpad work. but i noticed it's much more
> sensible (with leads to be very difficult to hit xmms' pause button :)
> than using it with noext option. is anyone working in an user level
> application to configure 2.6's synaptics touchpad driver?

Have you tried the

	http://w1.894.telia.com/~u89404340/touchpad/index.html

XFree86 driver?

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: keyboard repeat / sound [was Re: Linux 2.6.0-test6]
  2003-09-30 13:44           ` Vojtech Pavlik
@ 2003-09-30 14:05             ` Aristeu Sergio Rozanski Filho
  2003-09-30 14:16               ` Vojtech Pavlik
  2003-09-30 18:16               ` Mark W. Alexander
  0 siblings, 2 replies; 128+ messages in thread
From: Aristeu Sergio Rozanski Filho @ 2003-09-30 14:05 UTC (permalink / raw)
  To: Vojtech Pavlik; +Cc: Kernel Mailing List

> What problem exactly was that?
it repeats pressed keys too fast. sometimes it's even impossible to
type something without get repeated letters.
iirc, you wrote a mail days ago about how to help to debug
this. i may dig it and provide some extra information if you want.

> 	http://w1.894.telia.com/~u89404340/touchpad/index.html
> 
> XFree86 driver?
i didn't, i'll check this, thanks

-- 
aris


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: keyboard repeat / sound [was Re: Linux 2.6.0-test6]
  2003-09-30 14:05             ` Aristeu Sergio Rozanski Filho
@ 2003-09-30 14:16               ` Vojtech Pavlik
  2003-10-01 23:51                 ` Aristeu Sergio Rozanski Filho
  2003-09-30 18:16               ` Mark W. Alexander
  1 sibling, 1 reply; 128+ messages in thread
From: Vojtech Pavlik @ 2003-09-30 14:16 UTC (permalink / raw)
  To: Aristeu Sergio Rozanski Filho; +Cc: Vojtech Pavlik, Kernel Mailing List

On Tue, Sep 30, 2003 at 11:05:21AM -0300, Aristeu Sergio Rozanski Filho wrote:

> > What problem exactly was that?

> it repeats pressed keys too fast. sometimes it's even impossible to
> type something without get repeated letters.
> iirc, you wrote a mail days ago about how to help to debug
> this. i may dig it and provide some extra information if you want.

Ahh, I think I remember. Well, you can still try with atkbd_softrepeat=1
to see if the too fast autorepeat still happens if software autorepeat
is used. It doesn't work with test6, but test7 will hopefully include a
fix.

> > 	http://w1.894.telia.com/~u89404340/touchpad/index.html
> > 
> > XFree86 driver?
> i didn't, i'll check this, thanks
> 
> -- 
> aris
> 

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: keyboard repeat / sound [was Re: Linux 2.6.0-test6]
  2003-09-30 14:05             ` Aristeu Sergio Rozanski Filho
  2003-09-30 14:16               ` Vojtech Pavlik
@ 2003-09-30 18:16               ` Mark W. Alexander
  2003-10-01 23:52                 ` Aristeu Sergio Rozanski Filho
  1 sibling, 1 reply; 128+ messages in thread
From: Mark W. Alexander @ 2003-09-30 18:16 UTC (permalink / raw)
  To: Aristeu Sergio Rozanski Filho; +Cc: Vojtech Pavlik, Kernel Mailing List

On Tue, 30 Sep 2003, Aristeu Sergio Rozanski Filho wrote:

> > What problem exactly was that?
> it repeats pressed keys too fast. sometimes it's even impossible to
> type something without get repeated letters.
> iirc, you wrote a mail days ago about how to help to debug
> this. i may dig it and provide some extra information if you want.
> 
> > 	http://w1.894.telia.com/~u89404340/touchpad/index.html
> > 
> > XFree86 driver?
> i didn't, i'll check this, thanks

It also includes a synclient program to tweak settings on-the-fly,
which is very useful to tune it the way you like without restarting X
repeatedly.

-- 
Mark W. Alexander
slash@dotnetslash.net


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-09-28  1:27 Linux 2.6.0-test6 Linus Torvalds
                   ` (8 preceding siblings ...)
  2003-09-29 16:30 ` Linux 2.6.0-test6 (compile statistics) John Cherry
@ 2003-10-01  8:58 ` Mikael Pettersson
  2003-10-01 11:52   ` John Levon
  2003-10-01 15:11   ` Linus Torvalds
  9 siblings, 2 replies; 128+ messages in thread
From: Mikael Pettersson @ 2003-10-01  8:58 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Kernel Mailing List, perfctr-devel

Linus' 2.6.0-test6 announcement doesn't seem to mention the
fact that 2.6.0-test5-bk9 fundamentally changed the semantics
of /proc/self and the /proc/<pid> name space. These used to
map to actual (kernel) tasks, now they map to what I assume
are Posixly-correct processes (groups of tasks). In particular,
/proc/self is no longer an alias for `current'.

I don't actually disagree with the change, but it took me by
surprise since neither the 2.6.0-test6 annoucement nor the
diff between the t5-bk8 and t5-bk9 logs seem to mention it.

(It broke the perfctr driver, but I'm handling that by making
an already planned API switch now instead of later.)

/Mikael

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-01  8:58 ` Who changed /proc/<pid>/ in 2.6.0-test5-bk9? Mikael Pettersson
@ 2003-10-01 11:52   ` John Levon
  2003-10-01 20:21     ` bill davidsen
  2003-10-01 15:11   ` Linus Torvalds
  1 sibling, 1 reply; 128+ messages in thread
From: John Levon @ 2003-10-01 11:52 UTC (permalink / raw)
  To: Mikael Pettersson
  Cc: Linus Torvalds, Kernel Mailing List, perfctr-devel, albert

On Wed, Oct 01, 2003 at 10:58:08AM +0200, Mikael Pettersson wrote:

> Linus' 2.6.0-test6 announcement doesn't seem to mention the
> fact that 2.6.0-test5-bk9 fundamentally changed the semantics
> of /proc/self and the /proc/<pid> name space. These used to

Are these Albert Calahan's changes ?

For some reason I can't fathom they were sent privately to Linus without
them first being posted publicly anywhere ...

john

-- 
Khendon's Law:
If the same point is made twice by the same person, the thread is over.

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-01  8:58 ` Who changed /proc/<pid>/ in 2.6.0-test5-bk9? Mikael Pettersson
  2003-10-01 11:52   ` John Levon
@ 2003-10-01 15:11   ` Linus Torvalds
  2003-10-01 20:58     ` bill davidsen
                       ` (3 more replies)
  1 sibling, 4 replies; 128+ messages in thread
From: Linus Torvalds @ 2003-10-01 15:11 UTC (permalink / raw)
  To: Mikael Pettersson; +Cc: Kernel Mailing List, perfctr-devel, Albert Cahalan


On Wed, 1 Oct 2003, Mikael Pettersson wrote:
>
> Linus' 2.6.0-test6 announcement doesn't seem to mention the
> fact that 2.6.0-test5-bk9 fundamentally changed the semantics
> of /proc/self and the /proc/<pid> name space.

Well, that's because the semantics weren't _supposed_ to change. The new 
semantics were meant to be a superset of the old behaviour, with just the 
added "task" subdirectory that lists the actual threads.

However, you're right that "/proc/self" should likely point into the
_thread_, and not into the task. But it's debatable. You are very likely 
the only one who could ever care ;)

> I don't actually disagree with the change, but it took me by
> surprise since neither the 2.6.0-test6 annoucement nor the
> diff between the t5-bk8 and t5-bk9 logs seem to mention it.

Well, the changelog mentions "fix for hidden task problem", since the diff 
really is mainly to _add_ threads to the /proc layout. The fact that it 
changed /proc/self is actually a bit surprising. Albert?

> (It broke the perfctr driver, but I'm handling that by making
> an already planned API switch now instead of later.)

I think /proc/self most likely _should_ point into the thread, not the 
task. 

		Linus


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-01 11:52   ` John Levon
@ 2003-10-01 20:21     ` bill davidsen
  2003-10-02  1:00       ` John Levon
  0 siblings, 1 reply; 128+ messages in thread
From: bill davidsen @ 2003-10-01 20:21 UTC (permalink / raw)
  To: linux-kernel

In article <20031001115248.GC23819@compsoc.man.ac.uk>,
John Levon  <levon@movementarian.org> wrote:
| On Wed, Oct 01, 2003 at 10:58:08AM +0200, Mikael Pettersson wrote:
| 
| > Linus' 2.6.0-test6 announcement doesn't seem to mention the
| > fact that 2.6.0-test5-bk9 fundamentally changed the semantics
| > of /proc/self and the /proc/<pid> name space. These used to
| 
| Are these Albert Calahan's changes ?
| 
| For some reason I can't fathom they were sent privately to Linus without
| them first being posted publicly anywhere ...

I thought there had been discussion a while ago, but I can't put my
finger on it. In any case, I think the OP was noting that it was a
fairly impactful (is that a word?) change not to get a line in the
changelog. That's directed to whoever actually prepares the CL, not the
author of the patch.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-01 15:11   ` Linus Torvalds
@ 2003-10-01 20:58     ` bill davidsen
  2003-10-01 23:42     ` Albert Cahalan
                       ` (2 subsequent siblings)
  3 siblings, 0 replies; 128+ messages in thread
From: bill davidsen @ 2003-10-01 20:58 UTC (permalink / raw)
  To: linux-kernel

In article <Pine.LNX.4.44.0310010803530.23860-100000@home.osdl.org>,
Linus Torvalds  <torvalds@osdl.org> wrote:
| 
| On Wed, 1 Oct 2003, Mikael Pettersson wrote:
| >
| > Linus' 2.6.0-test6 announcement doesn't seem to mention the
| > fact that 2.6.0-test5-bk9 fundamentally changed the semantics
| > of /proc/self and the /proc/<pid> name space.
| 
| Well, that's because the semantics weren't _supposed_ to change. The new 
| semantics were meant to be a superset of the old behaviour, with just the 
| added "task" subdirectory that lists the actual threads.
| 
| However, you're right that "/proc/self" should likely point into the
| _thread_, and not into the task. But it's debatable. You are very likely 
| the only one who could ever care ;)

Well, it's a subtle detail, and it would be well to document such. He
may be the only person to use that, but it's certainly not intuitive,
and if I were to ever do this I'm certainly alerted that it might
violate Plauger's law of least astonishment. I would hope it points to
the thread, but if it doesn't it's not something I use every day ;-)
| 
| > I don't actually disagree with the change, but it took me by
| > surprise since neither the 2.6.0-test6 annoucement nor the
| > diff between the t5-bk8 and t5-bk9 logs seem to mention it.
| 
| Well, the changelog mentions "fix for hidden task problem", since the diff 
| really is mainly to _add_ threads to the /proc layout. The fact that it 
| changed /proc/self is actually a bit surprising. Albert?

When I get this one built I'm going to see which getpid() (and family)
returns as well, I never though of using /proc/self from a thread, but
I do on rare occasions get my pid.
| 
| > (It broke the perfctr driver, but I'm handling that by making
| > an already planned API switch now instead of later.)
| 
| I think /proc/self most likely _should_ point into the thread, not the 
| task. 

Hopefully that was an unintended side effect.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-30  1:12         ` Nick Piggin
@ 2003-10-01 21:13           ` bill davidsen
  2003-10-02  2:45             ` Nick Piggin
  0 siblings, 1 reply; 128+ messages in thread
From: bill davidsen @ 2003-10-01 21:13 UTC (permalink / raw)
  To: linux-kernel

In article <3F78D866.5070605@cyberone.com.au>,
Nick Piggin  <piggin@cyberone.com.au> wrote:
| 
| 
| bill davidsen wrote:
| 
| >In article <3F77BB2C.7030402@cyberone.com.au>,
| >Nick Piggin  <piggin@cyberone.com.au> wrote:
| >
| >| AFAIK, Con's scheduler doesn't change the nice implementation at all.
| >| Possibly some of his changes amplify its problems, or, more likely they
| >| remove most other scheduler problems leaving this one noticable.
| >| 
| >| If X is running at -20, and xmms at +19, xmms is supposed to still get
| >| 5% of the CPU. Should be enough to run fine. Unfortunately this is
| >| achieved by giving X very large timeslices, so xmms's scheduling latency
| >| becomes large. The interactivity bonuses don't help, either.
| >
| >Clearly the "some is good, more is better" approach doesn't provide
| >stable balance between sound and cpu hogs. It isn't a question of "how
| >much" cpu, just "when"which works or not.
| >
| >This is sort of like the deadline scheduler in that it trades of
| >throughput for avoiding jackpot cases. I think that's desired behaviour
| >in a CPU schedular too, at least if used by humans.
| >
| 
| I'm not sure what you mean. There is nothing good to say about Ingo's
| nice mechanism though (sorry Ingo, its otherwise a very nice
| scheduler!).

Oh, I think the test5-mm4 behaviour is far better than yours in terms of
throughput. I would expect that it could have several percent less
system time, leaving it for cpu-bound user processes. However, on my
little test machine (PII-350 w/ 96MB) running patch to get a kernel
source tree ready makes the system damn near unusable. With your v15
patch neither patch nor a kernel build is a real problem (I don't use
-j, there's only one processor and it doesn't help). I can happily read
mail, run windows to remote machines to do admin, check web based
monitors, and generally use the system. It's not a ball of fire, but
it's old and slow moving, and I can identify with that ;-)

| In my scheduler, nice -20 processes get small timeslices so scheduling
| latency stays low or even gets lower, while nice +19 ones get large
| timeslices for lower context switches and better cache efficiency. As
| you would like.

Clearly your timeslices don't get so large the system suffers. And I can
run setiathome with a little nice, like -5, and it will get some time
without slowing the important stuff on the system. Even at -19 it does
keep going. On a small memory machine I hate to give pages to a process
without giving it the CPU to justify the memory.

I'm going to try test5-n15 against test5-mm4 and test6-std with a server
load, but for now I run your patch on machines I use as personal
workstations. I haven't tried it SMP, that day will come.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-01 15:11   ` Linus Torvalds
  2003-10-01 20:58     ` bill davidsen
@ 2003-10-01 23:42     ` Albert Cahalan
  2003-10-02  0:38       ` Linus Torvalds
  2003-10-02  3:35     ` Ulrich Drepper
  2003-10-02  3:38     ` Ulrich Drepper
  3 siblings, 1 reply; 128+ messages in thread
From: Albert Cahalan @ 2003-10-01 23:42 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Mikael Pettersson, Kernel Mailing List, perfctr-devel, Albert Cahalan

On Wed, 2003-10-01 at 11:11, Linus Torvalds wrote:
> On Wed, 1 Oct 2003, Mikael Pettersson wrote:
> >
> > Linus' 2.6.0-test6 announcement doesn't seem to mention the
> > fact that 2.6.0-test5-bk9 fundamentally changed the semantics
> > of /proc/self and the /proc/<pid> name space.
> 
> Well, that's because the semantics weren't _supposed_ to change. The new 
> semantics were meant to be a superset of the old behaviour, with just the 
> added "task" subdirectory that lists the actual threads.
> 
> However, you're right that "/proc/self" should likely point into the
> _thread_, and not into the task. But it's debatable. You are very likely 
> the only one who could ever care ;)

That seems likely to break other stuff, as new-style
threads become more common. Right now, many tools are
unaware of new-style threads. Pointing at the tgid
directory (POSIX PID directory) lets tools ignore threads.

> > I don't actually disagree with the change, but it took me by
> > surprise since neither the 2.6.0-test6 annoucement nor the
> > diff between the t5-bk8 and t5-bk9 logs seem to mention it.
> 
> Well, the changelog mentions "fix for hidden task problem", since the diff 
> really is mainly to _add_ threads to the /proc layout. The fact that it 
> changed /proc/self is actually a bit surprising. Albert?

This is an interesting problem for sure. The link was
pointing to a directory that didn't get listed, except
that CLONE_THREAD wasn't exactly a popular feature yet.
So it was very seldom that the distinction mattered.

Currently, I rely on checking for /proc/self/task to
see if threads can be examined. Like this:

task_dir_missing = stat("/proc/self/task", &sbuf);

That wouldn't work if /proc/self pointed at the task.

It certainly seems to me that the intent of /proc/self is
to point to a "process", which is a tgid in kernel terms.
Back in the 2.4.xx days, that was a pid in kernel terms.
Now that we have CLONE_THREAD and the tgid, a "process"
is represented by the tgid. Pointing to the tgid matches
what other OSes do.

I think there is something clearly defective about having
the /proc/self link point to a hidden directory. It could
be pointed at /proc/42/task/58 and such I guess, but I
think tools could break as new-style threads begin to get
used in the real world.



^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: keyboard repeat / sound [was Re: Linux 2.6.0-test6]
  2003-09-30 14:16               ` Vojtech Pavlik
@ 2003-10-01 23:51                 ` Aristeu Sergio Rozanski Filho
  0 siblings, 0 replies; 128+ messages in thread
From: Aristeu Sergio Rozanski Filho @ 2003-10-01 23:51 UTC (permalink / raw)
  To: Vojtech Pavlik; +Cc: Kernel Mailing List

> Ahh, I think I remember. Well, you can still try with atkbd_softrepeat=1
> to see if the too fast autorepeat still happens if software autorepeat
> is used. It doesn't work with test6, but test7 will hopefully include a
> fix.
it's already fixed in test6 :)

thanks,

-- 
aris


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: keyboard repeat / sound [was Re: Linux 2.6.0-test6]
  2003-09-30 18:16               ` Mark W. Alexander
@ 2003-10-01 23:52                 ` Aristeu Sergio Rozanski Filho
  0 siblings, 0 replies; 128+ messages in thread
From: Aristeu Sergio Rozanski Filho @ 2003-10-01 23:52 UTC (permalink / raw)
  To: Mark W. Alexander; +Cc: Vojtech Pavlik, Kernel Mailing List

> > > 	http://w1.894.telia.com/~u89404340/touchpad/index.html
> > > 
> > > XFree86 driver?
> > i didn't, i'll check this, thanks
> 
> It also includes a synclient program to tweak settings on-the-fly,
> which is very useful to tune it the way you like without restarting X
> repeatedly.
it's working fine!

thanks :)

-- 
aris


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-01 23:42     ` Albert Cahalan
@ 2003-10-02  0:38       ` Linus Torvalds
  2003-10-02  0:57         ` Albert Cahalan
  0 siblings, 1 reply; 128+ messages in thread
From: Linus Torvalds @ 2003-10-02  0:38 UTC (permalink / raw)
  To: Albert Cahalan; +Cc: Mikael Pettersson, Kernel Mailing List, perfctr-devel


On 1 Oct 2003, Albert Cahalan wrote:
> 
> It certainly seems to me that the intent of /proc/self is
> to point to a "process", which is a tgid in kernel terms.

My argument against that is that it actually loses information. Now there 
is no way to easily look up the current thread stuff.

If /proc/self points to a thread, it's easy to look up the process with a 
"/proc/self/../..".

So in that sense it's a bad interface to point to the process, not the 
thread.

> I think there is something clearly defective about having
> the /proc/self link point to a hidden directory.

It's not hidden. It would just point to the real thread directory..

		Linus


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-29 16:55       ` Ed Sweetman
  2003-09-30  0:03         ` Nick Piggin
@ 2003-10-02  0:41         ` Pedro Larroy
  2003-10-02  3:05           ` Nick Piggin
  1 sibling, 1 reply; 128+ messages in thread
From: Pedro Larroy @ 2003-10-02  0:41 UTC (permalink / raw)
  To: linux-kernel

On Mon, Sep 29, 2003 at 12:55:12PM -0400, Ed Sweetman wrote:
> Nick Piggin wrote:
> >
> >
> >Rob Landley wrote:
> >
> >>On Sunday 28 September 2003 02:03, Con Kolivas wrote:
> >>
> >>>On Sun, 28 Sep 2003 11:27, Linus Torvalds wrote:
> >>>
> >>>>from Andrew Morton. Most notably perhaps Con's scheduler changes that
> >>>>have been discussed extensively and made it into the -mm tree for
> >>>>testing.
> >>>>
> >>>For those who are trying this for the first time, please note that the
> >>>scheduler has been tuned to tell the difference between tasks of the 
> >>>_same_
> >>>nice level. This means do NOT renice X or it will make audio skip unless
> >>>you also renice your audio application by the same amount. Lots of
> >>>distributions have done this for the old 2.4 scheduler which could not
> >>>treat equal "nice" levels as differently as the new scheduler does 
> >>>and 2.6
> >>>shouldn't need special treatment.
> >>>
> >>>So for testing note the following points:
> >>>
> >>>Make sure X is NOT reniced to -10 as many distributions are doing.
> >>>Some shells spawn processes at nice +5 by default and this will make 
> >>>audio
> >>>apps suffer.
> >>>Make sure your hard disk, graphics card and audio card are performing at
> >>>equal standard to your 2.4 kernel (ie dma is working, graphics is fully
> >>>accelerated etc).
> >>>
> >>
> >>I.E. with your new scheduler, priority levels actually have enough of 
> >>an effect now that things that aren't reniced can be noticeably 
> >>starved by things that are.
> >>
> >
> >AFAIK, Con's scheduler doesn't change the nice implementation at all.
> >Possibly some of his changes amplify its problems, or, more likely they
> >remove most other scheduler problems leaving this one noticable.
> >
> >If X is running at -20, and xmms at +19, xmms is supposed to still get
> >5% of the CPU. Should be enough to run fine. Unfortunately this is
> >achieved by giving X very large timeslices, so xmms's scheduling latency
> >becomes large. The interactivity bonuses don't help, either.
> >
> 
> there are 40 positions between -20 and 19, that doesn't equal 5% steps. 
> They don't even refer to % of cpu.  If i nice a process to -20 it 
> doesn't get a given percentage of cpu just because it's -20. I may have 
> other processes at -20 as well.  If you nice something to -20 and it is 
> actually using that cpu then things that are +19 shouldn't run and wont 
> run.  If I nice -20 vmstat 1, it's not going to starve xmms (or any 
> better audio player).  -20 means starve all and it should do that when 
> it actually makes use of the resources.
> 

Why not run xmms with SCHED_RR or SCHED_FIFO?


Regards.

        Pedro.


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-02  0:38       ` Linus Torvalds
@ 2003-10-02  0:57         ` Albert Cahalan
  0 siblings, 0 replies; 128+ messages in thread
From: Albert Cahalan @ 2003-10-02  0:57 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Albert Cahalan, Mikael Pettersson, Kernel Mailing List, perfctr-devel

On Wed, 2003-10-01 at 20:38, Linus Torvalds wrote:
> On 1 Oct 2003, Albert Cahalan wrote:
> > 
> > It certainly seems to me that the intent of /proc/self is
> > to point to a "process", which is a tgid in kernel terms.
> 
> My argument against that is that it actually loses information. Now there 
> is no way to easily look up the current thread stuff.

This maybe?

/proc/task -> 42/task/84

> If /proc/self points to a thread, it's easy to look up the process with a 
> "/proc/self/../..".

That wouldn't have worked with /proc/self pointing to
an invisible directory like it did. It could certainly
be made to work, like this:

/proc/self -> 42/task/84

Had the /proc/self code not been modified, you'd get
a nasty link like this:

/proc/self -> 84   (and "84" isn't listed in /proc)

So using "/proc/self/../.." would just go up to "/".
That's not too useful.



^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-01 20:21     ` bill davidsen
@ 2003-10-02  1:00       ` John Levon
  2003-10-06  3:01         ` bill davidsen
  0 siblings, 1 reply; 128+ messages in thread
From: John Levon @ 2003-10-02  1:00 UTC (permalink / raw)
  To: bill davidsen; +Cc: linux-kernel

On Wed, Oct 01, 2003 at 08:21:25PM +0000, bill davidsen wrote:

> finger on it. In any case, I think the OP was noting that it was a
> fairly impactful (is that a word?) change not to get a line in the
> changelog. That's directed to whoever actually prepares the CL, not the

It did get in the changelog (it's automated). It just didn't get sent
for public review at all.

john
-- 
Khendon's Law:
If the same point is made twice by the same person, the thread is over.

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-10-01 21:13           ` bill davidsen
@ 2003-10-02  2:45             ` Nick Piggin
  0 siblings, 0 replies; 128+ messages in thread
From: Nick Piggin @ 2003-10-02  2:45 UTC (permalink / raw)
  To: bill davidsen; +Cc: linux-kernel



bill davidsen wrote:

>In article <3F78D866.5070605@cyberone.com.au>,
>Nick Piggin  <piggin@cyberone.com.au> wrote:
>| 
>| 
>| bill davidsen wrote:
>| 
>| >In article <3F77BB2C.7030402@cyberone.com.au>,
>| >Nick Piggin  <piggin@cyberone.com.au> wrote:
>| >
>| >| AFAIK, Con's scheduler doesn't change the nice implementation at all.
>| >| Possibly some of his changes amplify its problems, or, more likely they
>| >| remove most other scheduler problems leaving this one noticable.
>| >| 
>| >| If X is running at -20, and xmms at +19, xmms is supposed to still get
>| >| 5% of the CPU. Should be enough to run fine. Unfortunately this is
>| >| achieved by giving X very large timeslices, so xmms's scheduling latency
>| >| becomes large. The interactivity bonuses don't help, either.
>| >
>| >Clearly the "some is good, more is better" approach doesn't provide
>| >stable balance between sound and cpu hogs. It isn't a question of "how
>| >much" cpu, just "when"which works or not.
>| >
>| >This is sort of like the deadline scheduler in that it trades of
>| >throughput for avoiding jackpot cases. I think that's desired behaviour
>| >in a CPU schedular too, at least if used by humans.
>| >
>| 
>| I'm not sure what you mean. There is nothing good to say about Ingo's
>| nice mechanism though (sorry Ingo, its otherwise a very nice
>| scheduler!).
>
>Oh, I think the test5-mm4 behaviour is far better than yours in terms of
>throughput. I would expect that it could have several percent less
>system time, leaving it for cpu-bound user processes. However, on my
>little test machine (PII-350 w/ 96MB) running patch to get a kernel
>source tree ready makes the system damn near unusable. With your v15
>patch neither patch nor a kernel build is a real problem (I don't use
>-j, there's only one processor and it doesn't help). I can happily read
>mail, run windows to remote machines to do admin, check web based
>monitors, and generally use the system. It's not a ball of fire, but
>it's old and slow moving, and I can identify with that ;-)
>
>| In my scheduler, nice -20 processes get small timeslices so scheduling
>| latency stays low or even gets lower, while nice +19 ones get large
>| timeslices for lower context switches and better cache efficiency. As
>| you would like.
>
>Clearly your timeslices don't get so large the system suffers. And I can
>run setiathome with a little nice, like -5, and it will get some time
>without slowing the important stuff on the system. Even at -19 it does
>keep going. On a small memory machine I hate to give pages to a process
>without giving it the CPU to justify the memory.
>
>I'm going to try test5-n15 against test5-mm4 and test6-std with a server
>load, but for now I run your patch on machines I use as personal
>workstations. I haven't tried it SMP, that day will come.
>

Oh ok, yeah. It does look like it might need some work to prevent
timeslices from getting too small. I'm going to start working on this
soon.



^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-10-02  0:41         ` Pedro Larroy
@ 2003-10-02  3:05           ` Nick Piggin
  2003-10-02 19:07             ` Pedro Larroy
  0 siblings, 1 reply; 128+ messages in thread
From: Nick Piggin @ 2003-10-02  3:05 UTC (permalink / raw)
  To: piotr; +Cc: linux-kernel



Pedro Larroy wrote:

>On Mon, Sep 29, 2003 at 12:55:12PM -0400, Ed Sweetman wrote:
>
>>Nick Piggin wrote:
>>
>>>
>>>Rob Landley wrote:
>>>
>>>
>>>>On Sunday 28 September 2003 02:03, Con Kolivas wrote:
>>>>
>>>>
>>>>>On Sun, 28 Sep 2003 11:27, Linus Torvalds wrote:
>>>>>
>>>>>>from Andrew Morton. Most notably perhaps Con's scheduler changes that
>>>>>
>>>>>>have been discussed extensively and made it into the -mm tree for
>>>>>>testing.
>>>>>>
>>>>>>
>>>>>For those who are trying this for the first time, please note that the
>>>>>scheduler has been tuned to tell the difference between tasks of the 
>>>>>_same_
>>>>>nice level. This means do NOT renice X or it will make audio skip unless
>>>>>you also renice your audio application by the same amount. Lots of
>>>>>distributions have done this for the old 2.4 scheduler which could not
>>>>>treat equal "nice" levels as differently as the new scheduler does 
>>>>>and 2.6
>>>>>shouldn't need special treatment.
>>>>>
>>>>>So for testing note the following points:
>>>>>
>>>>>Make sure X is NOT reniced to -10 as many distributions are doing.
>>>>>Some shells spawn processes at nice +5 by default and this will make 
>>>>>audio
>>>>>apps suffer.
>>>>>Make sure your hard disk, graphics card and audio card are performing at
>>>>>equal standard to your 2.4 kernel (ie dma is working, graphics is fully
>>>>>accelerated etc).
>>>>>
>>>>>
>>>>I.E. with your new scheduler, priority levels actually have enough of 
>>>>an effect now that things that aren't reniced can be noticeably 
>>>>starved by things that are.
>>>>
>>>>
>>>AFAIK, Con's scheduler doesn't change the nice implementation at all.
>>>Possibly some of his changes amplify its problems, or, more likely they
>>>remove most other scheduler problems leaving this one noticable.
>>>
>>>If X is running at -20, and xmms at +19, xmms is supposed to still get
>>>5% of the CPU. Should be enough to run fine. Unfortunately this is
>>>achieved by giving X very large timeslices, so xmms's scheduling latency
>>>becomes large. The interactivity bonuses don't help, either.
>>>
>>>
>>there are 40 positions between -20 and 19, that doesn't equal 5% steps. 
>>They don't even refer to % of cpu.  If i nice a process to -20 it 
>>doesn't get a given percentage of cpu just because it's -20. I may have 
>>other processes at -20 as well.  If you nice something to -20 and it is 
>>actually using that cpu then things that are +19 shouldn't run and wont 
>>run.  If I nice -20 vmstat 1, it's not going to starve xmms (or any 
>>better audio player).  -20 means starve all and it should do that when 
>>it actually makes use of the resources.
>>
>>
>
>Why not run xmms with SCHED_RR or SCHED_FIFO?
>
>

Well because playing an mp3 really is a pitiful task for modern CPUs,
and the standard scheduler should handle this fine. Also a music skip
isn't terribly important.

Realtime applications are difficult to make robust and they can easily
hang the system.


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-01 15:11   ` Linus Torvalds
  2003-10-01 20:58     ` bill davidsen
  2003-10-01 23:42     ` Albert Cahalan
@ 2003-10-02  3:35     ` Ulrich Drepper
  2003-10-02  4:12       ` Albert Cahalan
  2003-10-02  8:46       ` Who changed /proc/<pid>/ in 2.6.0-test5-bk9? Miquel van Smoorenburg
  2003-10-02  3:38     ` Ulrich Drepper
  3 siblings, 2 replies; 128+ messages in thread
From: Ulrich Drepper @ 2003-10-02  3:35 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Mikael Pettersson, Kernel Mailing List, Albert Cahalan

Linus Torvalds wrote:

> I think /proc/self most likely _should_ point into the thread, not the 
> task. 

As much as I want to not see this, I fear I have to agree.

There is, for instance, no guarantee that all CLONE_THREAD clones also
have CLONE_FILES set.  Then using /proc/self/%d for some thread-local
file descriptor will return the process group leaders file descriptor,
not the own.

-- 
--------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-01 15:11   ` Linus Torvalds
                       ` (2 preceding siblings ...)
  2003-10-02  3:35     ` Ulrich Drepper
@ 2003-10-02  3:38     ` Ulrich Drepper
  3 siblings, 0 replies; 128+ messages in thread
From: Ulrich Drepper @ 2003-10-02  3:38 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Mikael Pettersson, Kernel Mailing List, Albert Cahalan

> Then using /proc/self/%d for some thread-local

I menat of course /proc/self/fd/%d

-- 
--------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------



^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-02  3:35     ` Ulrich Drepper
@ 2003-10-02  4:12       ` Albert Cahalan
  2003-10-02  4:58         ` Ulrich Drepper
  2003-10-02  8:46       ` Who changed /proc/<pid>/ in 2.6.0-test5-bk9? Miquel van Smoorenburg
  1 sibling, 1 reply; 128+ messages in thread
From: Albert Cahalan @ 2003-10-02  4:12 UTC (permalink / raw)
  To: Ulrich Drepper
  Cc: Linus Torvalds, Mikael Pettersson, Kernel Mailing List, Albert Cahalan

On Wed, 2003-10-01 at 23:35, Ulrich Drepper wrote:
> Linus Torvalds wrote:
> 
> > I think /proc/self most likely _should_ point into the thread, not the 
> > task. 
> 
> As much as I want to not see this, I fear I have to agree.
> 
> There is, for instance, no guarantee that all CLONE_THREAD clones also
> have CLONE_FILES set.  Then using /proc/self/%d for some thread-local
> file descriptor will return the process group leaders file descriptor,
> not the own.

[meaning /proc/self/fd/%s instead]

In that case, don't you already have a severe mess?
For example, some kind of fd-related signal needs to
be delivered to the shared queue. So that happens,
but who can tell which "fd 42" it belongs with?

IMHO, if you want separate files, CLONE_THREAD should
not be in your clone() flags. (and then users call the
resulting thing a group of processes that share stuff,
instead of calling it a single process)

Also consider what the "fuser" and "lsof" programs must
do if threads don't share file descriptors. Ow, ow, ow!!!
These programs must scan /proc/*/task/*/fd/* to find all
open files. If threads share files, then "only" the tgid
level must be scanned.





^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-02  4:12       ` Albert Cahalan
@ 2003-10-02  4:58         ` Ulrich Drepper
  2003-10-02 13:48           ` Albert Cahalan
  0 siblings, 1 reply; 128+ messages in thread
From: Ulrich Drepper @ 2003-10-02  4:58 UTC (permalink / raw)
  To: Albert Cahalan; +Cc: Linus Torvalds, Mikael Pettersson, Kernel Mailing List

Albert Cahalan wrote:

> In that case, don't you already have a severe mess?
> [...]

That's all completely up to whoever decides to use this combination of
CLONE_* flags.  It might mean that SIGIO cannot be used and that fuser
cannot be used.  But so what?  That might be acceptable in that
situation.  What isn't acceptable is providing wrong information to the
program.  And this is not using a pointer to the kernel thread does.

Of course it could be redefined as "point to the process group leader"
but I'm not sure whether this and introducing "/proc/task" or so is
worth the trouble.

-- 
--------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-02  3:35     ` Ulrich Drepper
  2003-10-02  4:12       ` Albert Cahalan
@ 2003-10-02  8:46       ` Miquel van Smoorenburg
  2003-10-02 22:35         ` Jamie Lokier
  2003-10-06  2:57         ` bill davidsen
  1 sibling, 2 replies; 128+ messages in thread
From: Miquel van Smoorenburg @ 2003-10-02  8:46 UTC (permalink / raw)
  To: linux-kernel

In article <3F7B9CF9.4040706@redhat.com>,
Ulrich Drepper  <drepper@redhat.com> wrote:
>Linus Torvalds wrote:
>
>> I think /proc/self most likely _should_ point into the thread, not the 
>> task. 
>
>As much as I want to not see this, I fear I have to agree.
>
>There is, for instance, no guarantee that all CLONE_THREAD clones also
>have CLONE_FILES set.  Then using /proc/self/%d for some thread-local
>file descriptor will return the process group leaders file descriptor,
>not the own.

How about use /proc/self/task/self/fd/%d if /proc/self/task/self
exists, /proc/self/fd/%d otherwise ?

Mike.


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-02  4:58         ` Ulrich Drepper
@ 2003-10-02 13:48           ` Albert Cahalan
  2003-10-02 17:30             ` Ulrich Drepper
  0 siblings, 1 reply; 128+ messages in thread
From: Albert Cahalan @ 2003-10-02 13:48 UTC (permalink / raw)
  To: Ulrich Drepper
  Cc: Albert Cahalan, Linus Torvalds, Mikael Pettersson, Kernel Mailing List

On Thu, 2003-10-02 at 00:58, Ulrich Drepper wrote:
> Albert Cahalan wrote:
> 
> > In that case, don't you already have a severe mess?
> > [...]
> 
> That's all completely up to whoever decides to use this combination of
> CLONE_* flags.  It might mean that SIGIO cannot be used and that fuser
> cannot be used.  But so what?  That might be acceptable in that
> situation.

To the user, maybe. To the admin, no. The admin uses
fuser and/or lsof to find out why he can't umount.
If those programs were thread-aware (they are not),
then they could take many minutes to run.

In other words, stuff runs faster if we can ban this.
If not, please suggest a way to make fuser and lsof fast.

> Of course it could be redefined as "point to the process group leader"
> but I'm not sure whether this and introducing "/proc/task" or so is
> worth the trouble.

Adding a /proc/task isn't any more trouble.
I guess I'll do that in any case.

If /proc/self should be some deprecated hack that
goes through the invisible non-leader directories
at top-level, then it itself should be made invisible
and a /proc/proc (pointing to tgid) should be added.
A /proc/proc could be backported to 2.4.xx. We'd then
have top-level links for process (tgid, "proc", POSIX PID),
thread (pid, "task", POSIX TID), and... an ugly thing
that we can kill 5 years from now.



^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-02 13:48           ` Albert Cahalan
@ 2003-10-02 17:30             ` Ulrich Drepper
  2003-10-03  0:03               ` Albert Cahalan
  0 siblings, 1 reply; 128+ messages in thread
From: Ulrich Drepper @ 2003-10-02 17:30 UTC (permalink / raw)
  To: Albert Cahalan; +Cc: Linus Torvalds, Mikael Pettersson, Kernel Mailing List

Albert Cahalan wrote:

> To the user, maybe. To the admin, no. The admin uses
> fuser and/or lsof to find out why he can't umount.
> If those programs were thread-aware (they are not),
> then they could take many minutes to run.
> 
> In other words, stuff runs faster if we can ban this.
> If not, please suggest a way to make fuser and lsof fast.

Don't you see the flaw in your argumentation?

If lsof/fuser don't always handle this situation correctly you provide a
way for some ill-minded person to hide file descriptors from the view of
sysadmins etc.  You in any case have to handle this case.


It should be possible for a program to easily check whether

  /proc/PID/fd
and
  /proc/self/fd

are the same directory.  If not, add support for that.  Then those
programs only need to iterate over the fd directories and check whether
they are the same.

-- 
--------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-10-02  3:05           ` Nick Piggin
@ 2003-10-02 19:07             ` Pedro Larroy
  2003-10-03  0:07               ` Nick Piggin
  0 siblings, 1 reply; 128+ messages in thread
From: Pedro Larroy @ 2003-10-02 19:07 UTC (permalink / raw)
  To: Nick Piggin; +Cc: linux-kernel

On Thu, Oct 02, 2003 at 01:05:36PM +1000, Nick Piggin wrote:
> 
> 
> Pedro Larroy wrote:
> >Why not run xmms with SCHED_RR or SCHED_FIFO?
> >
> >
> 
> Well because playing an mp3 really is a pitiful task for modern CPUs,
> and the standard scheduler should handle this fine. Also a music skip
> isn't terribly important.
> 
> Realtime applications are difficult to make robust and they can easily
> hang the system.
> 

I think there are better aproaches for deciding when a task should be
interactive than the current one based in how much does the task sleep.

I'm afraid this selection criteria leads to a scheduler that isn't
predictable for situations that aren't the ones for which is tuned to work.
Of course I may be wrong, but to me, seems that saying explicitly 
which tasks are interactive sounds better.

-- 
  Pedro Larroy Tovar  |  piotr%member.fsf.org 

Software patents are a threat to innovation in Europe please check: 
	http://www.eurolinux.org/     

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-02  8:46       ` Who changed /proc/<pid>/ in 2.6.0-test5-bk9? Miquel van Smoorenburg
@ 2003-10-02 22:35         ` Jamie Lokier
  2003-10-02 23:43           ` Miquel van Smoorenburg
  2003-10-06  2:57         ` bill davidsen
  1 sibling, 1 reply; 128+ messages in thread
From: Jamie Lokier @ 2003-10-02 22:35 UTC (permalink / raw)
  To: Miquel van Smoorenburg; +Cc: linux-kernel

Miquel van Smoorenburg wrote:
> How about use /proc/self/task/self/fd/%d if /proc/self/task/self
> exists, /proc/self/fd/%d otherwise ?

/dev/stdin is a symbolic link to /proc/self/fd/0.

open("/dev/stdin", O_RDONLY) should always work, if descriptor 0 is readable.

Maybe you're saying /dev/stdin should be changed to link to
/proc/self/task/self/fd/0?

-- Jamie

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-02 22:35         ` Jamie Lokier
@ 2003-10-02 23:43           ` Miquel van Smoorenburg
  0 siblings, 0 replies; 128+ messages in thread
From: Miquel van Smoorenburg @ 2003-10-02 23:43 UTC (permalink / raw)
  To: linux-kernel

In article <20031002223550.GB13853@mail.shareable.org>,
Jamie Lokier  <jamie@shareable.org> wrote:
>Miquel van Smoorenburg wrote:
>> How about use /proc/self/task/self/fd/%d if /proc/self/task/self
>> exists, /proc/self/fd/%d otherwise ?
>
>/dev/stdin is a symbolic link to /proc/self/fd/0.
>
>open("/dev/stdin", O_RDONLY) should always work, if descriptor 0 is readable.
>
>Maybe you're saying /dev/stdin should be changed to link to
>/proc/self/task/self/fd/0?

You're right, that would not fly. Scrap that idea.

Mike.


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-02 17:30             ` Ulrich Drepper
@ 2003-10-03  0:03               ` Albert Cahalan
  2003-10-03  0:40                 ` Linus Torvalds
  2003-10-07 22:46                 ` Robert White
  0 siblings, 2 replies; 128+ messages in thread
From: Albert Cahalan @ 2003-10-03  0:03 UTC (permalink / raw)
  To: Ulrich Drepper
  Cc: Albert Cahalan, Linus Torvalds, Mikael Pettersson, Kernel Mailing List

On Thu, 2003-10-02 at 13:30, Ulrich Drepper wrote:
> Albert Cahalan wrote:
> 
> > To the user, maybe. To the admin, no. The admin uses
> > fuser and/or lsof to find out why he can't umount.
> > If those programs were thread-aware (they are not),
> > then they could take many minutes to run.
> > 
> > In other words, stuff runs faster if we can ban this.
> > If not, please suggest a way to make fuser and lsof fast.
> 
> Don't you see the flaw in your argumentation?

No. I mean "ban" like we ban CLONE_THREAD w/o CLONE_DETACHED.
Remember, the last stable release of the kernel (2.4.xx)
didn't have the ability to do CLONE_THREAD at all. So it
isn't as if real-world apps are depending on the ability
to do CLONE_THREAD w/o sharing file descriptors.

Got a legitimate must-have real-world use for it?



^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-10-02 19:07             ` Pedro Larroy
@ 2003-10-03  0:07               ` Nick Piggin
  2003-10-03 19:34                 ` Pedro Larroy
  0 siblings, 1 reply; 128+ messages in thread
From: Nick Piggin @ 2003-10-03  0:07 UTC (permalink / raw)
  To: piotr; +Cc: linux-kernel



Pedro Larroy wrote:

>On Thu, Oct 02, 2003 at 01:05:36PM +1000, Nick Piggin wrote:
>
>>
>>Pedro Larroy wrote:
>>
>>>Why not run xmms with SCHED_RR or SCHED_FIFO?
>>>
>>>
>>>
>>Well because playing an mp3 really is a pitiful task for modern CPUs,
>>and the standard scheduler should handle this fine. Also a music skip
>>isn't terribly important.
>>
>>Realtime applications are difficult to make robust and they can easily
>>hang the system.
>>
>>
>
>I think there are better aproaches for deciding when a task should be
>interactive than the current one based in how much does the task sleep.
>
>I'm afraid this selection criteria leads to a scheduler that isn't
>predictable for situations that aren't the ones for which is tuned to work.
>Of course I may be wrong, but to me, seems that saying explicitly 
>which tasks are interactive sounds better.
>

Have a look at my scheduler if you like. It won't estimate interactivity
but it works quite well if you nice -10 your X server. Ie. explicitly
state which process should be favoured.
http://www.kerneltrap.org/~npiggin/v15a/


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-03  0:03               ` Albert Cahalan
@ 2003-10-03  0:40                 ` Linus Torvalds
  2003-10-03  2:53                   ` Jamie Lokier
                                     ` (2 more replies)
  2003-10-07 22:46                 ` Robert White
  1 sibling, 3 replies; 128+ messages in thread
From: Linus Torvalds @ 2003-10-03  0:40 UTC (permalink / raw)
  To: Albert Cahalan; +Cc: Ulrich Drepper, Mikael Pettersson, Kernel Mailing List


On 2 Oct 2003, Albert Cahalan wrote:
> 
> No. I mean "ban" like we ban CLONE_THREAD w/o CLONE_DETACHED.

No. Let's not do that.

We ban only things that do not make sense. That was true of trying to 
share signal handlers with different address spaces. But it is _not_ true 
of having separate file descriptors for different threads.

I don't imagine anybody cares _that_ deeply about fuser that it can't 
afford to recurse into thread directories.

And it may or may not make sense to not have a "/proc/<nn>/task/<yy>/fd"
directory at all if the thread shares file descriptors with the thread 
group leader. That would be a fairly easy optimization.

		Linus


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-03  0:40                 ` Linus Torvalds
@ 2003-10-03  2:53                   ` Jamie Lokier
  2003-10-06  4:54                     ` Mike Fedyk
  2003-10-06  2:52                   ` bill davidsen
  2003-10-07 23:08                   ` Robert White
  2 siblings, 1 reply; 128+ messages in thread
From: Jamie Lokier @ 2003-10-03  2:53 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Albert Cahalan, Ulrich Drepper, Mikael Pettersson, Kernel Mailing List

Linus Torvalds wrote:
> And it may or may not make sense to not have a "/proc/<nn>/task/<yy>/fd"
> directory at all if the thread shares file descriptors with the thread 
> group leader. That would be a fairly easy optimization.

If you make /proc/.../fd return the same inode numbers for the
identical file descriptor tables, that would be just as good for fuser
performance.

fuser would stat() each of the /proc/<nn>/task/<yy>/fd entries and see
that they're the same as the group leader.

It is the same number of operations as checking for the non-existence
of /proc/<nn>/task/<yy>/fd entries, but more flexible.

Alternatively you could make the task fd directories be symbolic
links to the group leader fd directory.

-- Jamie

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-10-03  0:07               ` Nick Piggin
@ 2003-10-03 19:34                 ` Pedro Larroy
  0 siblings, 0 replies; 128+ messages in thread
From: Pedro Larroy @ 2003-10-03 19:34 UTC (permalink / raw)
  To: Nick Piggin; +Cc: linux-kernel

On Fri, Oct 03, 2003 at 10:07:48AM +1000, Nick Piggin wrote:
> 
> Have a look at my scheduler if you like. It won't estimate interactivity
> but it works quite well if you nice -10 your X server. Ie. explicitly
> state which process should be favoured.
> http://www.kerneltrap.org/~npiggin/v15a/
> 

I will.

Have you made available any tools you used to debug the scheduler? I think
it would be useful to characterize last time the process got a chance to
run to measure the timeslices and the quantums that are being given.

Regards.
-- 
  Pedro Larroy Tovar  |  piotr%member.fsf.org 

Software patents are a threat to innovation in Europe please check: 
	http://www.eurolinux.org/     

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-03  0:40                 ` Linus Torvalds
  2003-10-03  2:53                   ` Jamie Lokier
@ 2003-10-06  2:52                   ` bill davidsen
  2003-10-07 23:08                   ` Robert White
  2 siblings, 0 replies; 128+ messages in thread
From: bill davidsen @ 2003-10-06  2:52 UTC (permalink / raw)
  To: linux-kernel

In article <Pine.LNX.4.44.0310021720510.7833-100000@home.osdl.org>,
Linus Torvalds  <torvalds@osdl.org> wrote:
| 
| On 2 Oct 2003, Albert Cahalan wrote:
| > 
| > No. I mean "ban" like we ban CLONE_THREAD w/o CLONE_DETACHED.
| 
| No. Let's not do that.
| 
| We ban only things that do not make sense. That was true of trying to 
| share signal handlers with different address spaces. But it is _not_ true 
| of having separate file descriptors for different threads.
| 
| I don't imagine anybody cares _that_ deeply about fuser that it can't 
| afford to recurse into thread directories.
| 
| And it may or may not make sense to not have a "/proc/<nn>/task/<yy>/fd"
| directory at all if the thread shares file descriptors with the thread 
| group leader. That would be a fairly easy optimization.

I think Albert has a good point on performance, since nothing is using
the ability to have separate fd sets, I can't see it as a requirement.
However, I have an application which has a lot of files and sockets
open, and I think having the separation may make things far nicer when
not all the threads need have everything open.

But if there are going to be both kinds of threaded processes, there
should be a good way to tell if a program like lsof needs to chase every
thread or not. I'm not totally sure what Albert has in mind for
/proc/task, but if there were a way to create subdirs only for threads
with separate fd space, that would be one approach.

lsof is painful now, hopefully for things which share fd it can be much
faster.

And how does this new capability fit with SUS, if at all?
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-02  8:46       ` Who changed /proc/<pid>/ in 2.6.0-test5-bk9? Miquel van Smoorenburg
  2003-10-02 22:35         ` Jamie Lokier
@ 2003-10-06  2:57         ` bill davidsen
  1 sibling, 0 replies; 128+ messages in thread
From: bill davidsen @ 2003-10-06  2:57 UTC (permalink / raw)
  To: linux-kernel

In article <blgol5$vd0$1@news.cistron.nl>,
Miquel van Smoorenburg <miquels@cistron.nl> wrote:
| In article <3F7B9CF9.4040706@redhat.com>,
| Ulrich Drepper  <drepper@redhat.com> wrote:
| >Linus Torvalds wrote:
| >
| >> I think /proc/self most likely _should_ point into the thread, not the 
| >> task. 
| >
| >As much as I want to not see this, I fear I have to agree.
| >
| >There is, for instance, no guarantee that all CLONE_THREAD clones also
| >have CLONE_FILES set.  Then using /proc/self/%d for some thread-local
| >file descriptor will return the process group leaders file descriptor,
| >not the own.
| 
| How about use /proc/self/task/self/fd/%d if /proc/self/task/self
| exists, /proc/self/fd/%d otherwise ?

Let me bend your suggestion slightly and suggest that for a task which
shares fd with the leader, /proc/N/task/M/fd would be a symlink to
/proc/M/fd, and if fd's were not shared it would be a directory. That
would make it easy for programs like lsof to know when to look and whn
not.

This doesn't prevent your suggestion which triggered the thought, it
just seems to avoid having a boatload of symlinks for the most common
case when one would do.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-02  1:00       ` John Levon
@ 2003-10-06  3:01         ` bill davidsen
  0 siblings, 0 replies; 128+ messages in thread
From: bill davidsen @ 2003-10-06  3:01 UTC (permalink / raw)
  To: linux-kernel

In article <20031002010054.GA13639@compsoc.man.ac.uk>,
John Levon  <levon@movementarian.org> wrote:
| On Wed, Oct 01, 2003 at 08:21:25PM +0000, bill davidsen wrote:
| 
| > finger on it. In any case, I think the OP was noting that it was a
| > fairly impactful (is that a word?) change not to get a line in the
| > changelog. That's directed to whoever actually prepares the CL, not the
| 
| It did get in the changelog (it's automated). It just didn't get sent
| for public review at all.

Actually, while there was an entry for the change, it didn't mention
that there was a major interface rethink. In that particular case I
believe a human should have been in the loop.

Just a comment, not major issue.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-03  2:53                   ` Jamie Lokier
@ 2003-10-06  4:54                     ` Mike Fedyk
  0 siblings, 0 replies; 128+ messages in thread
From: Mike Fedyk @ 2003-10-06  4:54 UTC (permalink / raw)
  To: Jamie Lokier
  Cc: Linus Torvalds, Albert Cahalan, Ulrich Drepper,
	Mikael Pettersson, Kernel Mailing List

On Fri, Oct 03, 2003 at 03:53:38AM +0100, Jamie Lokier wrote:
> Alternatively you could make the task fd directories be symbolic
> links to the group leader fd directory.

Now this sounds good.  It also shows more information (and no need to follow
symlinks, so fuser/lsof can be fast).

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6 (compile statistics)
  2003-09-29 17:44   ` Jesper Juhl
@ 2003-10-06 20:39     ` John Cherry
  0 siblings, 0 replies; 128+ messages in thread
From: John Cherry @ 2003-10-06 20:39 UTC (permalink / raw)
  To: Jesper Juhl; +Cc: Linus Torvalds, Kernel Mailing List

On Mon, 2003-09-29 at 10:44, Jesper Juhl wrote:
[snip]
> 
> I was wondering if there would be any point in doing these builds with
> "allnoconfig" as well?
> Could this possibly flush out some warnings/errors that only occur when
> something is left out?
> 
> 

The compile regressions now build with allnoconfig as well for both
Linus' tree and Andrew's tree.  Check out...

http://developer.osdl.org/cherry/compile/

BTW, the latest compile stats for test6-mm3 and test6-mm4 are:

Kernel version: 2.6.0-test6-mm4
Kernel build: 
   Making bzImage (defconfig): 0 warnings, 0 errors
   Making modules (defconfig): 0 warnings, 0 errors
   Making bzImage (allnoconfig): 1 warnings, 0 errors
   Making bzImage (allyesconfig): 179 warnings, 1 errors
   Making modules (allyesconfig): 9 warnings, 0 errors
   Making bzImage (allmodconfig): 3 warnings, 0 errors
   Making modules (allmodconfig): 234 warnings, 1 errors

Kernel version: 2.6.0-test6-mm3
Kernel build: 
   Making bzImage (defconfig): 0 warnings, 0 errors
   Making modules (defconfig): 0 warnings, 0 errors
   Making bzImage (allnoconfig): 1 warnings, 0 errors
   Making bzImage (allyesconfig): 178 warnings, 1 errors
   Making modules (allyesconfig): 9 warnings, 0 errors
   Making bzImage (allmodconfig): 3 warnings, 0 errors
   Making modules (allmodconfig): 252 warnings, 1 errors


John


^ permalink raw reply	[flat|nested] 128+ messages in thread

* RE: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-03  0:03               ` Albert Cahalan
  2003-10-03  0:40                 ` Linus Torvalds
@ 2003-10-07 22:46                 ` Robert White
  2003-10-07 23:25                   ` Linus Torvalds
  1 sibling, 1 reply; 128+ messages in thread
From: Robert White @ 2003-10-07 22:46 UTC (permalink / raw)
  To: 'Albert Cahalan', 'Ulrich Drepper'
  Cc: 'Linus Torvalds', 'Mikael Pettersson',
	'Kernel Mailing List'

I can say that (virtually) any programmer who does a lot of threads work is
going to presume that he may pass file handles between threads safely.

IMHO it would be exceptionally bad to break this assumption.

At the purist level, when I pass an abstraction (data structure etc) around
between my threads, having done my due-diligence WRT locking and such, I
expect that when the abstraction gets there it will still be valid.

Consider:

class ObjectList { /* whatever */ };

class CachedObjectList: public ObjectList {
    iostream	SlowStorage;
    /* whatever */
};

/* global, locks not shown */ vector<ObjectList*> central_registry;

One would *expect* that one could add CachedObjectList objects to the
central registry and then use them in any thread as long as access/locking
paradigms were strictly followed.

If every thread *doesn't* have the exact same set of files open in exactly
the same handles, this would not be true.

I would go as far as saying that if CLONE_THREAD *MUST* imply CLONE_FILES
automatically or Very Bad Things(tm) could happen.

For instance, if two threads have opened different files as fd==10, when the
shared data structure above passed from one thread to the other (with
SlowStorage attached to fd 10), the buffered output from the first task
could get flushed into the file opened by the second thread at whatever its
write pointer happens to be set to.  Etc.

Rob. 


-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Albert Cahalan
Sent: Thursday, October 02, 2003 5:03 PM
To: Ulrich Drepper
Cc: Albert Cahalan; Linus Torvalds; Mikael Pettersson; Kernel Mailing List
Subject: Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?


No. I mean "ban" like we ban CLONE_THREAD w/o CLONE_DETACHED.
Remember, the last stable release of the kernel (2.4.xx)
didn't have the ability to do CLONE_THREAD at all. So it
isn't as if real-world apps are depending on the ability
to do CLONE_THREAD w/o sharing file descriptors.





^ permalink raw reply	[flat|nested] 128+ messages in thread

* RE: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-03  0:40                 ` Linus Torvalds
  2003-10-03  2:53                   ` Jamie Lokier
  2003-10-06  2:52                   ` bill davidsen
@ 2003-10-07 23:08                   ` Robert White
  2 siblings, 0 replies; 128+ messages in thread
From: Robert White @ 2003-10-07 23:08 UTC (permalink / raw)
  To: 'Linus Torvalds', 'Albert Cahalan'
  Cc: 'Ulrich Drepper', 'Mikael Pettersson',
	'Kernel Mailing List'

Howdy,

All threads within the same process must have the same (single) list of open
files or bad things will happen.  I understand that CLONE_FILES makes this
true at the time of the clone but I don't know if that keeps this true
thereafter (e.g I don't know if this is a copy-that or a share-that
operation).  If it doesn't, the some mechanism that does needs to be added.

If all the co-joined threads of a process share the same file descriptor
list then /proc/self/fd/* will have unity for the overall process and the
bulk of the argument disappears completely.

The reason the threads must share the file descriptor table involves the
fact that data may, and likely will, flow between the threads.  After the
open(2) call the file descriptor is just data and it will get shared.

For instance, I have a seriously multi-threaded server application.  The
listen() operation for new clients happens in one thread.  When a connection
is accept()ed I take the request (first bit of data) and match it to the
service (and therefore thread) that it should be attached too.  Then I had
that socket over to that thread.

Without the shared file descriptors this would break very badly.

Conversely, there is virtually no sane model where having a disjoint file
descriptor list but otherwise conjoined data space makes sense.  The file
descriptors are going to be "tarnishing" the data space if you do this, and
that is just begging for exploits and "surprises".  That is, you will end up
with little tidbits of data that are conditionally meaningful scattered
throughout your data space.

Where you need to have the initial data shared but differing descriptor
tables you *should* be "stuck" with a classic fork() operation.

What possible win could you have in having a variable contain a particular
integral quantity that is a data file open for reading in one thread, a
mapped segment of memory in another, and invalid in the rest?  If you don't
constrain that behavior now the resulting code that "depends" on this
behavior will plague this platform for years (see Windows Dynamic Data
Exchange) and lots of existing expectations for thread behavior will be
violated day-1 of the release.

IMHO of course 8-)

Rob.


-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Linus Torvalds
Sent: Thursday, October 02, 2003 5:41 PM
To: Albert Cahalan
Cc: Ulrich Drepper; Mikael Pettersson; Kernel Mailing List
Subject: Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?


On 2 Oct 2003, Albert Cahalan wrote:
> 
> No. I mean "ban" like we ban CLONE_THREAD w/o CLONE_DETACHED.

No. Let's not do that.

We ban only things that do not make sense. That was true of trying to 
share signal handlers with different address spaces. But it is _not_ true 
of having separate file descriptors for different threads.

I don't imagine anybody cares _that_ deeply about fuser that it can't 
afford to recurse into thread directories.

And it may or may not make sense to not have a "/proc/<nn>/task/<yy>/fd"
directory at all if the thread shares file descriptors with the thread 
group leader. That would be a fairly easy optimization.

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



^ permalink raw reply	[flat|nested] 128+ messages in thread

* RE: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-07 22:46                 ` Robert White
@ 2003-10-07 23:25                   ` Linus Torvalds
  2003-10-08  0:41                     ` Robert White
  0 siblings, 1 reply; 128+ messages in thread
From: Linus Torvalds @ 2003-10-07 23:25 UTC (permalink / raw)
  To: Robert White
  Cc: 'Albert Cahalan', 'Ulrich Drepper',
	'Mikael Pettersson', 'Kernel Mailing List'


On Tue, 7 Oct 2003, Robert White wrote:
>
> I can say that (virtually) any programmer who does a lot of threads work is
> going to presume that he may pass file handles between threads safely.
> 
> IMHO it would be exceptionally bad to break this assumption.

That's not true.

It's true that if you use the pthreads model, you'll pass fd's between 
threads freely.

But there are lots of other valid thread usages. Many of the original uses 
of Linux threading were for special-case apps which used the clone() 
interface directly. Some were games, where the native threading stuff was 
doing things like sound etc in the background.

And when you have _that_ kind of model (with assymetric specialized 
threads), it makes perfect sense for the threads to have independent file 
descriptors.

> At the purist level, when I pass an abstraction (data structure etc) around
> between my threads, having done my due-diligence WRT locking and such, I
> expect that when the abstraction gets there it will still be valid.

And that is what you get with pthreads.

But the native Linux threading has never been pthreads. It's been about a 
much more generic thing, where the user is in control of what he does.

And that, btw, implies that thread nazis that only use pthreads do _not_ 
get to determine what the rest of the world does.

		Linus


^ permalink raw reply	[flat|nested] 128+ messages in thread

* RE: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-07 23:25                   ` Linus Torvalds
@ 2003-10-08  0:41                     ` Robert White
  2003-10-08  0:54                       ` Linus Torvalds
                                         ` (2 more replies)
  0 siblings, 3 replies; 128+ messages in thread
From: Robert White @ 2003-10-08  0:41 UTC (permalink / raw)
  To: 'Linus Torvalds'
  Cc: 'Albert Cahalan', 'Ulrich Drepper',
	'Mikael Pettersson', 'Kernel Mailing List'



-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Linus Torvalds


> And when you have _that_ kind of model (with assymetric specialized 
> threads), it makes perfect sense for the threads to have independent file 
> descriptors.

(Preface disclaimer) I don't "just use pthreads" as the other half of my
life is embedded work using RTXC (od nausium 8-) and on occasion windows
nonsense.  I've also used the LWP features of solaris without the pthread
library.  I experience the differences between the posix thread and the
lightweight process paradigms daily.

What is gained by having the independent file descriptor context that would
be *broken* for lack of that independence?

Even in a game or for very specialized threads that don't talk much if at
all, can you give me one example where two threads simply *must* have the
same file descriptor number active for two separate files at the same time?

That is, where this is the truth table for FDs:

         Thread-A  Thread-B
          File-X    File-Y
Works:     10        10
Broken:    10        11

I can, truthfully, think of two models only.

In the first model each thread is managing FILES_MAX separate files (or at
least THREADS times FILES_PER_THREAD may reasonably exceed FILES_MAX for the
whole process space).  In short, you only "need" to do this if you are
expecting slam up against the maximum open files limit beyond the ability of
the system administrator to extend that limit.

In the second, one has a data space image (process etc) shared across
multiple computers (clustering) or times (restore-from-sleep) and one is
trying to coerce file handle numbers to match the common data without
kernel-level assistance.  And for this one every mental simulation I can
envision ends up stonewalled when the overseer thread tires to make the
overseen image get the right things connected up in "the other" file
descriptor table.

Both models are impractical, and the first can (and you allege already do)
exist using existing options (e.g. not using CLONE_THREAD).

The only other conceivable reason for having two different files open with
the same descriptor number is if you are trying to match up with a system
that requires that the numbers themselves have specific values.  I know of
no such code except for the establishment of standard input (etc) before an
exec().

Since the fork-and-exec model is the only time when certain files simply
must have certain descriptors, and since that is done after the fork, there
is no place imaginable where a running process with multiple threads "needs"
particular descriptor numbers.

So either model can be created and essentially supported in the current code
base.

But should it be?

Here we are with my betters discussing the /proc/self/fd/* (etc) question.
So a lot of effort is being expended to allow a feature (separate file
descriptor tables in conjoined threads) with the consequent complexities in
all the related stuff (fuser etc, elaborated elsewhere in the thread) simply
to create the opportunity for more and interesting errors in a new feature.

You said it yourself (or at least I inferred you to say it 8-), for the
pthread stuff this will not happen anyway because the clone operation
can/will be called by the library with CLONE_FILES set anyway.

Perhaps I am a lesser being, but were the need to arise to do this specific
decoupling, wouldn't this be done using the old semantics anyway?

So CLONE_THREAD is supposed to create (essentially) the conjoined LWP
environment in as much as you are creating a "thread within a process", but
you want to decouple "file" from "process" to separately and multiply
re-couple it with each "thread".  Yet further, you want to leave "file"
bound to "process" if there is only one thread.  That is an expensive
change, especially when it is apparently being done case-by-case. You aren't
unilaterally redefining "process" to be a set of one or more threads, if you
were /proc/<pid>/fd/* would have to disappear in favor of
/proc/<pid>/<tid>/fd/* and /proc/self would mutate into a set of dynamic
references, some to /proc/<pid>/<tid>/whatever and some to just
/proc/<pid>/whatever.

Isn't the complexity itself an indicator of a fracturing paradigm?

What does the paradiagmatic hole around the file descriptor table buy again?


Rob.



^ permalink raw reply	[flat|nested] 128+ messages in thread

* RE: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-08  0:41                     ` Robert White
@ 2003-10-08  0:54                       ` Linus Torvalds
  2003-10-08  2:31                         ` Robert White
                                           ` (2 more replies)
  2003-10-09 17:59                       ` bill davidsen
  2003-10-11  3:02                       ` Here is a case that proves my previous position wrong regurading CLONE_THREAD and CLONE_FILES Robert White
  2 siblings, 3 replies; 128+ messages in thread
From: Linus Torvalds @ 2003-10-08  0:54 UTC (permalink / raw)
  To: Robert White
  Cc: 'Albert Cahalan', 'Ulrich Drepper',
	'Mikael Pettersson', 'Kernel Mailing List'


On Tue, 7 Oct 2003, Robert White wrote:
> 
> What is gained by having the independent file descriptor context that would
> be *broken* for lack of that independence?

You're coming at it from the wrong end. Sharing resources is inherently
bad. If there is no reason to share, you shouldn't share.

The reason people use threads is that sharing the VM space has real 
advantages: it makes context switching much cheaper (fewer hw resources in 
the form of TLB usages) and it allows for much faster synchronization 
through a shared address space.

But the same isn't true of file descriptors or a lot of other software-
level abstractions. There are no inherent advantages to sharing, and in
fact sharing just gives more opportunity for race conditions, bad
interaction etc.

For example, one reason _not_ to share is that the subthread may want to 
be as invisible to the "main thread" as possible. That's just good 
programming practice - trying to isolate and encapsulate as much data as 
possible.

The same way you shouldn't make all your variables global, you shouldn't 
make all your data structures global unless you have a reason.

		Linus


^ permalink raw reply	[flat|nested] 128+ messages in thread

* RE: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-08  0:54                       ` Linus Torvalds
@ 2003-10-08  2:31                         ` Robert White
  2003-10-08  2:39                           ` David Lang
  2003-10-08  2:47                           ` Who changed /proc/<pid>/ in 2.6.0-test5-bk9? (SIGPIPE?) Robert White
  2003-10-08 10:47                         ` Who changed /proc/<pid>/ in 2.6.0-test5-bk9? bert hubert
  2003-10-09 18:12                         ` bill davidsen
  2 siblings, 2 replies; 128+ messages in thread
From: Robert White @ 2003-10-08  2:31 UTC (permalink / raw)
  To: 'Linus Torvalds'
  Cc: 'Albert Cahalan', 'Ulrich Drepper',
	'Mikael Pettersson', 'Kernel Mailing List'

<holistic theoretical rumination>

I guess my disconnect happens at the "what do you mean by process" level.

To me, the idea of a process is defined at the heat/light barrier with the
kernel.  A process has unity of interface.  That is, everything on "my side"
of the all encompassing interface is one process, one "me".  File
descriptors are not (in this view) "software level abstractions", they can't
be because they exist beyond the control of the application side of the
process, they must then be properties of the interface between process and
kernel.  That makes them inherently a defining property of the boundary
between "process" and "world".

A "thread" (ne "thread of control") is any one pathway of fact of execution
taking place on "my side" which sees the world through that interface.
Threads within their process are organs within the common function of a
single entity.  They are not independent and they come and go at the
sufferance of the whole.  Threads are organs in the body of a process (even
the posix-style "detached" thread, which is only "detached" in the
who-waits-for-whom when someone dies/exits sense).

There is the implication of singularity to that interface in the use of
those two words.  That singularity exists as expressed fact in the /proc
filesystem as it exists today and I suspect, were you to take a poll, that
is the way most people would think about the words.  (Not that more than
half the people are right about anything more than half the time. 8-)

Without this compositing what makes up the differences between "process"
"process group" "thread" and "thread group".  I doubt I am the only one
confused:

>From 2.6.0-test5:

File: include/linux/sched.h (lines 47 and 53)
#define CLONE_THREAD    0x00010000      /* Same thread group? */
#define CLONE_DETACHED  0x00400000      /* Not used - CLONE_THREAD implies
detached uniquely */

File: kernel/fork.c (line 778) [copy_process]
printk(KERN_WARNING "%s trying to use CLONE_THREAD without CLONE_DETACH\n",
current->comm);


The same implicit unity-of-interface is part-and-parcel of the requirement
that the signal handlers must be the same. 


Now when different processes "just" share the same VM; e.g. the thing that
the current (2.4 and prior) kernels do where you (only) clone the virtual
memory system (etc); has never really felt "thread-like" to me.  I hunger to
give it a different name.  They are like conjoined twins.  They have this
common connection, this body, but they have their separate interface to the
rest of the world.  Their sense of self is distinct even though their bodies
are melded in a poison-one-both-die reality.

The problem is we are trying to cram three paradigms into two words.

So anyway, posix people (yes I know 8-) talk about the M:N relationship (M
posix-threads on N LWPs [or do I have that backwards 8-)]).

The old linux kernel models P:1.  We create a new process, no matter what,
which may be copied or conjoined as we see fit.

The truth is that the new kernel models P:M:N because we can do both the old
thing and the new thing since the techniques are not exclusive of one
another.

When you start with one unified process image you can clone() it in any of
the old ways and produce the conjoined twins (e.g. do a P++ operation).
When you clone with CLONE_THREAD you really ought to be doing an "M++".
Whether the posix thread library does a N++ or an M++ operation for a
pthread_create call is neither here nor there.  And there is no reason that
you cannot conjoin-clone and thread-clone repeatedly and variously from the
same basic seed entity.

The natural extension of this logic would be to simply state that
CLONE_THREAD makes a thread instead of a conjoined clone thingy that you get
in the absence of this flag.  And being a thread, the new entity "will" have
the expected unity of interface as the price of being "more than twins".

In the resulting model there is no /proc/<pid>/<tid>/fd directory because
the unity of process puts it all in /proc/<pid>/fd.  The almost everything
in /proc/<pid>/<tid> is a simlink up one level.  The primary members are the
thread specific cpu and status accumulators/control points.  Similarly the
cpu and status/control points for "non-threaded" process can be implemented
entirely within (unilaterally moved to) /proc/<pid>/<the-only-tid> with
simlinks in /proc/<pid> to /proc/<pid>/<the-only-tid> for everyting but cpu,
and cpu is unilaterally the summary of all the tid(s) of which there happens
to be just one.

It's deterministic.
It's unified.
It will surprise the least number of people. 
It loses no options or features.
It's completely backward compatible.
The distinction between CLONE_THREAD and (CLONE_SIGHAND|CLONE_VM[|CLONE_FS])
remains clear, functional, and valuable.

</holistic theoretical rumination>

Rob.

-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Linus Torvalds
Sent: Tuesday, October 07, 2003 5:55 PM
To: Robert White
Cc: 'Albert Cahalan'; 'Ulrich Drepper'; 'Mikael Pettersson'; 'Kernel Mailing
List'
Subject: RE: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?


On Tue, 7 Oct 2003, Robert White wrote:
> 
> What is gained by having the independent file descriptor context that
would
> be *broken* for lack of that independence?

You're coming at it from the wrong end. Sharing resources is inherently
bad. If there is no reason to share, you shouldn't share.

The reason people use threads is that sharing the VM space has real 
advantages: it makes context switching much cheaper (fewer hw resources in 
the form of TLB usages) and it allows for much faster synchronization 
through a shared address space.

But the same isn't true of file descriptors or a lot of other software-
level abstractions. There are no inherent advantages to sharing, and in
fact sharing just gives more opportunity for race conditions, bad
interaction etc.

For example, one reason _not_ to share is that the subthread may want to 
be as invisible to the "main thread" as possible. That's just good 
programming practice - trying to isolate and encapsulate as much data as 
possible.

The same way you shouldn't make all your variables global, you shouldn't 
make all your data structures global unless you have a reason.

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



^ permalink raw reply	[flat|nested] 128+ messages in thread

* RE: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-08  2:31                         ` Robert White
@ 2003-10-08  2:39                           ` David Lang
  2003-10-08  2:59                             ` Robert White
  2003-10-08  2:47                           ` Who changed /proc/<pid>/ in 2.6.0-test5-bk9? (SIGPIPE?) Robert White
  1 sibling, 1 reply; 128+ messages in thread
From: David Lang @ 2003-10-08  2:39 UTC (permalink / raw)
  To: Robert White
  Cc: 'Linus Torvalds', 'Albert Cahalan',
	'Ulrich Drepper', 'Mikael Pettersson',
	'Kernel Mailing List'

Robert, you are missing the point. Linux allows you to share or not share
each item.

if you think you always want to share file descriptors you can,
if you don't you can isolate them

if you want 'traditional' threads just share everything

however just becouse you don't see a reason why someone would want to
isolate threads from each other for a particular thing don't assume that
there isn't and never will be such a reason and argue to have that
flexibility removed.

other OS's have 'fork a process' and 'spawn a thread' that are completely
different from each other and you have no other options.

Linux has 'clone this process/thread and share the following items', fork
is a special case of clone where you share nothing, spawn is a special
case where you share everything, but there is that huge middle ground
that's open for future use.

keep things flexible, expecially when it makes the underlying code simpler
(and as a side effect faster and more reliable)

David Lang

On Tue, 7 Oct 2003, Robert White wrote:

> Date: Tue, 7 Oct 2003 19:31:04 -0700
> From: Robert White <rwhite@casabyte.com>
> To: 'Linus Torvalds' <torvalds@osdl.org>
> Cc: 'Albert Cahalan' <albert@users.sourceforge.net>,
>      'Ulrich Drepper' <drepper@redhat.com>,
>      'Mikael Pettersson' <mikpe@csd.uu.se>,
>      'Kernel Mailing List' <linux-kernel@vger.kernel.org>
> Subject: RE: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
>
> <holistic theoretical rumination>
>
> I guess my disconnect happens at the "what do you mean by process" level.
>
> To me, the idea of a process is defined at the heat/light barrier with the
> kernel.  A process has unity of interface.  That is, everything on "my side"
> of the all encompassing interface is one process, one "me".  File
> descriptors are not (in this view) "software level abstractions", they can't
> be because they exist beyond the control of the application side of the
> process, they must then be properties of the interface between process and
> kernel.  That makes them inherently a defining property of the boundary
> between "process" and "world".
>
> A "thread" (ne "thread of control") is any one pathway of fact of execution
> taking place on "my side" which sees the world through that interface.
> Threads within their process are organs within the common function of a
> single entity.  They are not independent and they come and go at the
> sufferance of the whole.  Threads are organs in the body of a process (even
> the posix-style "detached" thread, which is only "detached" in the
> who-waits-for-whom when someone dies/exits sense).
>
> There is the implication of singularity to that interface in the use of
> those two words.  That singularity exists as expressed fact in the /proc
> filesystem as it exists today and I suspect, were you to take a poll, that
> is the way most people would think about the words.  (Not that more than
> half the people are right about anything more than half the time. 8-)
>
> Without this compositing what makes up the differences between "process"
> "process group" "thread" and "thread group".  I doubt I am the only one
> confused:
>
> From 2.6.0-test5:
>
> File: include/linux/sched.h (lines 47 and 53)
> #define CLONE_THREAD    0x00010000      /* Same thread group? */
> #define CLONE_DETACHED  0x00400000      /* Not used - CLONE_THREAD implies
> detached uniquely */
>
> File: kernel/fork.c (line 778) [copy_process]
> printk(KERN_WARNING "%s trying to use CLONE_THREAD without CLONE_DETACH\n",
> current->comm);
>
>
> The same implicit unity-of-interface is part-and-parcel of the requirement
> that the signal handlers must be the same.
>
>
> Now when different processes "just" share the same VM; e.g. the thing that
> the current (2.4 and prior) kernels do where you (only) clone the virtual
> memory system (etc); has never really felt "thread-like" to me.  I hunger to
> give it a different name.  They are like conjoined twins.  They have this
> common connection, this body, but they have their separate interface to the
> rest of the world.  Their sense of self is distinct even though their bodies
> are melded in a poison-one-both-die reality.
>
> The problem is we are trying to cram three paradigms into two words.
>
> So anyway, posix people (yes I know 8-) talk about the M:N relationship (M
> posix-threads on N LWPs [or do I have that backwards 8-)]).
>
> The old linux kernel models P:1.  We create a new process, no matter what,
> which may be copied or conjoined as we see fit.
>
> The truth is that the new kernel models P:M:N because we can do both the old
> thing and the new thing since the techniques are not exclusive of one
> another.
>
> When you start with one unified process image you can clone() it in any of
> the old ways and produce the conjoined twins (e.g. do a P++ operation).
> When you clone with CLONE_THREAD you really ought to be doing an "M++".
> Whether the posix thread library does a N++ or an M++ operation for a
> pthread_create call is neither here nor there.  And there is no reason that
> you cannot conjoin-clone and thread-clone repeatedly and variously from the
> same basic seed entity.
>
> The natural extension of this logic would be to simply state that
> CLONE_THREAD makes a thread instead of a conjoined clone thingy that you get
> in the absence of this flag.  And being a thread, the new entity "will" have
> the expected unity of interface as the price of being "more than twins".
>
> In the resulting model there is no /proc/<pid>/<tid>/fd directory because
> the unity of process puts it all in /proc/<pid>/fd.  The almost everything
> in /proc/<pid>/<tid> is a simlink up one level.  The primary members are the
> thread specific cpu and status accumulators/control points.  Similarly the
> cpu and status/control points for "non-threaded" process can be implemented
> entirely within (unilaterally moved to) /proc/<pid>/<the-only-tid> with
> simlinks in /proc/<pid> to /proc/<pid>/<the-only-tid> for everyting but cpu,
> and cpu is unilaterally the summary of all the tid(s) of which there happens
> to be just one.
>
> It's deterministic.
> It's unified.
> It will surprise the least number of people.
> It loses no options or features.
> It's completely backward compatible.
> The distinction between CLONE_THREAD and (CLONE_SIGHAND|CLONE_VM[|CLONE_FS])
> remains clear, functional, and valuable.
>
> </holistic theoretical rumination>
>
> Rob.
>
> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org
> [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Linus Torvalds
> Sent: Tuesday, October 07, 2003 5:55 PM
> To: Robert White
> Cc: 'Albert Cahalan'; 'Ulrich Drepper'; 'Mikael Pettersson'; 'Kernel Mailing
> List'
> Subject: RE: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
>
>
> On Tue, 7 Oct 2003, Robert White wrote:
> >
> > What is gained by having the independent file descriptor context that
> would
> > be *broken* for lack of that independence?
>
> You're coming at it from the wrong end. Sharing resources is inherently
> bad. If there is no reason to share, you shouldn't share.
>
> The reason people use threads is that sharing the VM space has real
> advantages: it makes context switching much cheaper (fewer hw resources in
> the form of TLB usages) and it allows for much faster synchronization
> through a shared address space.
>
> But the same isn't true of file descriptors or a lot of other software-
> level abstractions. There are no inherent advantages to sharing, and in
> fact sharing just gives more opportunity for race conditions, bad
> interaction etc.
>
> For example, one reason _not_ to share is that the subthread may want to
> be as invisible to the "main thread" as possible. That's just good
> programming practice - trying to isolate and encapsulate as much data as
> possible.
>
> The same way you shouldn't make all your variables global, you shouldn't
> make all your data structures global unless you have a reason.
>
> 		Linus
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

^ permalink raw reply	[flat|nested] 128+ messages in thread

* RE: Who changed /proc/<pid>/ in 2.6.0-test5-bk9? (SIGPIPE?)
  2003-10-08  2:31                         ` Robert White
  2003-10-08  2:39                           ` David Lang
@ 2003-10-08  2:47                           ` Robert White
  2003-10-08  2:57                             ` Linus Torvalds
  1 sibling, 1 reply; 128+ messages in thread
From: Robert White @ 2003-10-08  2:47 UTC (permalink / raw)
  To: 'Robert White', 'Linus Torvalds'
  Cc: 'Albert Cahalan', 'Ulrich Drepper',
	'Mikael Pettersson', 'Kernel Mailing List'



PS this may be dumb but...

If all the CLONE_THREAD members of a process (automatically) have the same
signal handling code/context but not the same list of file descriptors, what
happens when a file descriptor posts SIGPIPE or SIGIO (etc.) to a process?

Rob.



^ permalink raw reply	[flat|nested] 128+ messages in thread

* RE: Who changed /proc/<pid>/ in 2.6.0-test5-bk9? (SIGPIPE?)
  2003-10-08  2:47                           ` Who changed /proc/<pid>/ in 2.6.0-test5-bk9? (SIGPIPE?) Robert White
@ 2003-10-08  2:57                             ` Linus Torvalds
  2003-10-08  4:01                               ` Robert White
  0 siblings, 1 reply; 128+ messages in thread
From: Linus Torvalds @ 2003-10-08  2:57 UTC (permalink / raw)
  To: Robert White
  Cc: 'Albert Cahalan', 'Ulrich Drepper',
	'Mikael Pettersson', 'Kernel Mailing List'


On Tue, 7 Oct 2003, Robert White wrote:
> 
> If all the CLONE_THREAD members of a process (automatically) have the same
> signal handling code/context but not the same list of file descriptors, what
> happens when a file descriptor posts SIGPIPE or SIGIO (etc.) to a process?

You have to explicitly _ask_ for SIGIO. If you do so, and you don't share
file descriptors, that's _your_ problem.

But it does indeed have perfectly valid semantics - the signal may well
just wake up a thread: and in fact, as most IO is illegal in signal
handler context anyway, it usually has to. 

Clearly, if you have per-thread file descriptors, you have to keep track 
of which thread is doing what. 

		Linus


^ permalink raw reply	[flat|nested] 128+ messages in thread

* RE: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-08  2:39                           ` David Lang
@ 2003-10-08  2:59                             ` Robert White
  2003-10-09 18:25                               ` bill davidsen
  0 siblings, 1 reply; 128+ messages in thread
From: Robert White @ 2003-10-08  2:59 UTC (permalink / raw)
  To: 'David Lang'
  Cc: 'Linus Torvalds', 'Albert Cahalan',
	'Ulrich Drepper', 'Mikael Pettersson',
	'Kernel Mailing List'

Actually, the point I am trying to _make_ is that Linux allows you to share
or not share each item (already) but making a coherent "thread" implies a
unity of interface over the entities.  We already have VM and Signals in
that unity, but not file descriptors.  I think that's bad.  Since the old
way lets me have this 2/3-of-a-thread already.  When I ask for a thread I
should get a thread, not just a composite of otherwise identical shareable
options.

After all, if I deliver SIGPIPE to a "process" and it gets serviced by one
of the "theads" how does the "thread" know the file descriptor in the signal
is from its own file descriptor table?  If the signals are only going to the
specific member threads and, in fact NOT to the "process", then how is the
sharing of signal context anything more than a renaming of what is already
there as of 2.2?

If CLONE_THREAD exists solely to reproduce the existing
(CLONE_VM|CLONE_SIGHAND[|CLONE_whatever]) functionality, why did anybody
bother doing more than a #define?

Presumably CLONE_THREAD is supposed to make a LWP (in the classic sense)
that runs with view of the kernel that is consistent with all its peer LWPs.
If not, it is going to surprise a heck of a lot of (posix AND non posix)
thread programmers worldwide.  "They ought to know better" has merit, but
that merit is equal to "they might as well use the old stuff".

Rob.

-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of David Lang
Sent: Tuesday, October 07, 2003 7:39 PM
To: Robert White
Cc: 'Linus Torvalds'; 'Albert Cahalan'; 'Ulrich Drepper'; 'Mikael
Pettersson'; 'Kernel Mailing List'
Subject: RE: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?

Robert, you are missing the point. Linux allows you to share or not share
each item.
.



^ permalink raw reply	[flat|nested] 128+ messages in thread

* RE: Who changed /proc/<pid>/ in 2.6.0-test5-bk9? (SIGPIPE?)
  2003-10-08  2:57                             ` Linus Torvalds
@ 2003-10-08  4:01                               ` Robert White
  2003-10-08  4:08                                 ` Linus Torvalds
  0 siblings, 1 reply; 128+ messages in thread
From: Robert White @ 2003-10-08  4:01 UTC (permalink / raw)
  To: 'Linus Torvalds'
  Cc: 'Albert Cahalan', 'Ulrich Drepper',
	'Mikael Pettersson', 'Kernel Mailing List'

So I have two threads that are doing IO on a file descriptors with the
number 5, I get an unexpected EPIPE on "5", now what?  I kept track.  Who is
it for?

Yea, I know:

1) add the other flag to clone()
2) mask the signal off completely
3) wake everybody who has a 5 in their file descriptor table (except that I
can't see anybody elses' file descriptor table)
4) wake everybody
5) let the owner task notice the problem when it gets back around to using
"5"
5) Just die like a good little program

Since it doesn't do all the things I expect from the common definition of
"thread"; and it isn't documented anywhere I can find online or in the
kernel tree; what is the kernel actually promising me when I use
CLONE_THREAD anyway?  How is it more than (CLONE_VM|CLONE_SIGHAND)?

[I see a bit about exiting as a group and I assume that CPU usage statistics
are aggregated amongst the threads.  Is that it?]

And I'll bet two dollars I won't be the last to ask... 8-)

You've seen my other arguments about expectation and consistency so I'll
stop now, I promise. 8-)

Rob.

-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Linus Torvalds
Sent: Tuesday, October 07, 2003 7:58 PM
To: Robert White
Cc: 'Albert Cahalan'; 'Ulrich Drepper'; 'Mikael Pettersson'; 'Kernel Mailing
List'
Subject: RE: Who changed /proc/<pid>/ in 2.6.0-test5-bk9? (SIGPIPE?)


On Tue, 7 Oct 2003, Robert White wrote:
> 
> If all the CLONE_THREAD members of a process (automatically) have the same
> signal handling code/context but not the same list of file descriptors,
what
> happens when a file descriptor posts SIGPIPE or SIGIO (etc.) to a process?

You have to explicitly _ask_ for SIGIO. If you do so, and you don't share
file descriptors, that's _your_ problem.

But it does indeed have perfectly valid semantics - the signal may well
just wake up a thread: and in fact, as most IO is illegal in signal
handler context anyway, it usually has to. 

Clearly, if you have per-thread file descriptors, you have to keep track 
of which thread is doing what. 

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



^ permalink raw reply	[flat|nested] 128+ messages in thread

* RE: Who changed /proc/<pid>/ in 2.6.0-test5-bk9? (SIGPIPE?)
  2003-10-08  4:01                               ` Robert White
@ 2003-10-08  4:08                                 ` Linus Torvalds
  0 siblings, 0 replies; 128+ messages in thread
From: Linus Torvalds @ 2003-10-08  4:08 UTC (permalink / raw)
  To: Robert White
  Cc: 'Albert Cahalan', 'Ulrich Drepper',
	'Mikael Pettersson', 'Kernel Mailing List'


On Tue, 7 Oct 2003, Robert White wrote:
>
> So I have two threads that are doing IO on a file descriptors with the
> number 5, I get an unexpected EPIPE on "5", now what?  I kept track.  Who is
> it for?

Robert. We get it. You don't like having separate file descriptors.

Fine. Don't use them. What's your point?

Why the hell do you think you have the right to say that others can't use
them? Just because you don't like them? Or just because you made a
contrieved example of SIGPIPE (which kills the process if not caught, and
is usually ignored if actually expected, since the EPIPE error return is a
lot more convenient and is thread-safe, btw)?

Feel free to continue arguing with yourself or on the mailing list, but 
please don't cc me. I'm not interested. I'm definitely "pro-choice" when 
it comes to people writing their user level applications, and I just can't 
get interested in the fact that you don't like them.

		Linus


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-08  0:54                       ` Linus Torvalds
  2003-10-08  2:31                         ` Robert White
@ 2003-10-08 10:47                         ` bert hubert
  2003-10-08 19:12                           ` Ulrich Drepper
  2003-10-08 21:54                           ` Robert White
  2003-10-09 18:12                         ` bill davidsen
  2 siblings, 2 replies; 128+ messages in thread
From: bert hubert @ 2003-10-08 10:47 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Robert White, 'Albert Cahalan', 'Ulrich Drepper',
	'Mikael Pettersson', 'Kernel Mailing List'

On Tue, Oct 07, 2003 at 05:54:35PM -0700, Linus Torvalds wrote:

> But the same isn't true of file descriptors or a lot of other software-
> level abstractions. There are no inherent advantages to sharing, and in
> fact sharing just gives more opportunity for race conditions, bad
> interaction etc.

I may be missing something, I'm all for the ability to have threads with
their own fd namespace, but will NPTL/Linux retain the capability to pass
fd's to other threads?

One thing I've used in tens of programs is:

void *session(void *p)
{
	int fd=(int)p;
	...
}
...

for(;;) {
	fd=accept();
	pthread_create_thread(session,(void*)fd);
}

I'd like to continue to have that ability.

Thanks.

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-08 10:47                         ` Who changed /proc/<pid>/ in 2.6.0-test5-bk9? bert hubert
@ 2003-10-08 19:12                           ` Ulrich Drepper
  2003-10-09 18:43                             ` bill davidsen
  2003-10-08 21:54                           ` Robert White
  1 sibling, 1 reply; 128+ messages in thread
From: Ulrich Drepper @ 2003-10-08 19:12 UTC (permalink / raw)
  To: bert hubert; +Cc: 'Kernel Mailing List'

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

bert hubert wrote:

> I may be missing something, I'm all for the ability to have threads with
> their own fd namespace, but will NPTL/Linux retain the capability to pass
> fd's to other threads?


Grr, somebody should have killed this thread before these pointless,
irritating, and simply wrong arguments were made by the White fella.
Exactly because it's irritating many readers as can be witnessed above.


The kernel thread functionality is not used 1-to-1 in the userlevel
interfaces of the pthread library.  One very specific combination of all
the CLONE_* flags is used in libpthread.  Other users of the kernel
might use other combinations and they won't implement pthreads.  That
is perfectly fine and if it fits your bill, do it.  But none of this
ever has any influence on the pthread interface.  The properties like
sharing of file descriptors are guaranteed.

If somebody insists in future to discuss kernel "thread" related issues,
use the term "clone" instead of "thread".  This will keep the irritation
level down.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/hGGD2ijCOnn/RHQRAv54AJ0XYGVQ1Iawhwm237eULPP4lFeK9ACfSrc2
A8XJuJGBecVfACkEAVPmYrA=
=EGWH
-----END PGP SIGNATURE-----


^ permalink raw reply	[flat|nested] 128+ messages in thread

* RE: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-08 10:47                         ` Who changed /proc/<pid>/ in 2.6.0-test5-bk9? bert hubert
  2003-10-08 19:12                           ` Ulrich Drepper
@ 2003-10-08 21:54                           ` Robert White
  1 sibling, 0 replies; 128+ messages in thread
From: Robert White @ 2003-10-08 21:54 UTC (permalink / raw)
  To: 'bert hubert', 'Linus Torvalds'
  Cc: 'Albert Cahalan', 'Ulrich Drepper',
	'Mikael Pettersson', 'Kernel Mailing List'

Actually, the pthread library is at a higher level than the clone() system
call (where I was phrasing my debate.)

That library already does "the right thing" by requesting that the file
descriptors be shared explicitly.  It must for the pthread paradigm to work.
Therefore it presumably still will.

That is libpthread "does" and "should" make the requests for new OS threads
with the unified file descriptor table case.  So the below will keep working
as expected.

I was barking up a different tree with my arguments.  (e.g. what is the
minimal definition of thread in the mind of the kernel.)

So unless the pthread implementer makes a mistake, the POSIX level of
abstraction will be right regardless.

Rob.

-----Original Message-----
From: bert hubert [mailto:ahu@ds9a.nl] 
Sent: Wednesday, October 08, 2003 3:47 AM
To: Linus Torvalds
Cc: Robert White; 'Albert Cahalan'; 'Ulrich Drepper'; 'Mikael Pettersson';
'Kernel Mailing List'
Subject: Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?

On Tue, Oct 07, 2003 at 05:54:35PM -0700, Linus Torvalds wrote:

> But the same isn't true of file descriptors or a lot of other software-
> level abstractions. There are no inherent advantages to sharing, and in
> fact sharing just gives more opportunity for race conditions, bad
> interaction etc.

I may be missing something, I'm all for the ability to have threads with
their own fd namespace, but will NPTL/Linux retain the capability to pass
fd's to other threads?

One thing I've used in tens of programs is:

void *session(void *p)
{
	int fd=(int)p;
	...
}
...

for(;;) {
	fd=accept();
	pthread_create_thread(session,(void*)fd);
}

I'd like to continue to have that ability.

Thanks.

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO



^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-08  0:41                     ` Robert White
  2003-10-08  0:54                       ` Linus Torvalds
@ 2003-10-09 17:59                       ` bill davidsen
  2003-10-11  3:02                       ` Here is a case that proves my previous position wrong regurading CLONE_THREAD and CLONE_FILES Robert White
  2 siblings, 0 replies; 128+ messages in thread
From: bill davidsen @ 2003-10-09 17:59 UTC (permalink / raw)
  To: linux-kernel

In article <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA2ZSI4XW+fk25FhAf9BqjtMKAAAAQAAAAwtz+A6aJAkeufXSGK2GIiwEAAAAA@casabyte.com>,
Robert White <rwhite@casabyte.com> wrote:
| 
| 
| -----Original Message-----
| From: linux-kernel-owner@vger.kernel.org
| [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Linus Torvalds
| 
| 
| > And when you have _that_ kind of model (with assymetric specialized 
| > threads), it makes perfect sense for the threads to have independent file 
| > descriptors.
| 
| (Preface disclaimer) I don't "just use pthreads" as the other half of my
| life is embedded work using RTXC (od nausium 8-) and on occasion windows
| nonsense.  I've also used the LWP features of solaris without the pthread
| library.  I experience the differences between the posix thread and the
| lightweight process paradigms daily.
| 
| What is gained by having the independent file descriptor context that would
| be *broken* for lack of that independence?

To start with, if I have a server with 1400 clients, instead of 1400
threads with 1400(+overhead) fd's each, I have 1400 threads with
1(+overhead) fd's. While memory waste is "broken" the way you mean, it
is significant.

And since one thread can close a file which it's done with it, without
affecting all the other threads, or open a file without forcing it into
all other threads, so system overhead is reduced there as well.

| Even in a game or for very specialized threads that don't talk much if at
| all, can you give me one example where two threads simply *must* have the
| same file descriptor number active for two separate files at the same time?
| 
| That is, where this is the truth table for FDs:

The truth table is "if you don't like the way it works don't use it."
Since this only affects programs which choose to use it you can pretend
it isn't there.

| So CLONE_THREAD is supposed to create (essentially) the conjoined LWP
| environment in as much as you are creating a "thread within a process", but
| you want to decouple "file" from "process" to separately and multiply
| re-couple it with each "thread".  Yet further, you want to leave "file"
| bound to "process" if there is only one thread.  That is an expensive
| change, especially when it is apparently being done case-by-case. You aren't
| unilaterally redefining "process" to be a set of one or more threads, if you
| were /proc/<pid>/fd/* would have to disappear in favor of
| /proc/<pid>/<tid>/fd/* and /proc/self would mutate into a set of dynamic
| references, some to /proc/<pid>/<tid>/whatever and some to just
| /proc/<pid>/whatever.

I have already suggested that traditional threads just have their fd be
a symlink to the main process fd, making it easy to identify, and for
non-fd-sharing threads have the fd entries which refer to inherited fd's
also be symlinks. Others have independently made the same or similar
suggestions. What you suggest would seem to break existing software
which expects an fd directory in /proc/<pid>.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-08  0:54                       ` Linus Torvalds
  2003-10-08  2:31                         ` Robert White
  2003-10-08 10:47                         ` Who changed /proc/<pid>/ in 2.6.0-test5-bk9? bert hubert
@ 2003-10-09 18:12                         ` bill davidsen
  2003-10-10  4:39                           ` Jamie Lokier
  2 siblings, 1 reply; 128+ messages in thread
From: bill davidsen @ 2003-10-09 18:12 UTC (permalink / raw)
  To: linux-kernel

In article <Pine.LNX.4.44.0310071743370.32358-100000@home.osdl.org>,
Linus Torvalds  <torvalds@osdl.org> wrote:

| The reason people use threads is that sharing the VM space has real 
| advantages: it makes context switching much cheaper (fewer hw resources in 
| the form of TLB usages) and it allows for much faster synchronization 
| through a shared address space.
| 
| But the same isn't true of file descriptors or a lot of other software-
| level abstractions. There are no inherent advantages to sharing, and in
| fact sharing just gives more opportunity for race conditions, bad
| interaction etc.

That depends on what you're doing. It can be lower cost to have threads
putting fd's on a chain to be serviced by another thread than to start
another thread to do the service and use IPC to do serialization
between threads. And abstractions like SysV message queues are
inherently shared. Sometimes there are savings to be had by sharing.

Your base point that resources shouldn't be shared needlessly is
correct, or course.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-08  2:59                             ` Robert White
@ 2003-10-09 18:25                               ` bill davidsen
  0 siblings, 0 replies; 128+ messages in thread
From: bill davidsen @ 2003-10-09 18:25 UTC (permalink / raw)
  To: linux-kernel

In article <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA2ZSI4XW+fk25FhAf9BqjtMKAAAAQAAAAG15dxRiudEualTNpHNYqMgEAAAAA@casabyte.com>,
Robert White <rwhite@casabyte.com> wrote:
| Actually, the point I am trying to _make_ is that Linux allows you to share
| or not share each item (already) but making a coherent "thread" implies a
| unity of interface over the entities.  We already have VM and Signals in
| that unity, but not file descriptors.  I think that's bad.  Since the old
| way lets me have this 2/3-of-a-thread already.  When I ask for a thread I
| should get a thread, not just a composite of otherwise identical shareable
| options.

I think you have wrapped yourself in nomenclature, and by using your own
definitions of terms in strictly traditional meanings you have  created
problems which aren't really there.

If you don't like it don't use it. If you insist on your own definition
of "thread" then your paragraph above may have meaning, but since your
definition doesn't seem to match the way Linux is going to work, I'm not
sure it's meaningful in any relevant context.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-08 19:12                           ` Ulrich Drepper
@ 2003-10-09 18:43                             ` bill davidsen
  0 siblings, 0 replies; 128+ messages in thread
From: bill davidsen @ 2003-10-09 18:43 UTC (permalink / raw)
  To: linux-kernel

In article <3F846183.9010205@redhat.com>,
Ulrich Drepper  <drepper@redhat.com> wrote:

| The kernel thread functionality is not used 1-to-1 in the userlevel
| interfaces of the pthread library.  One very specific combination of all
| the CLONE_* flags is used in libpthread.  Other users of the kernel
| might use other combinations and they won't implement pthreads.  That
| is perfectly fine and if it fits your bill, do it.  But none of this
| ever has any influence on the pthread interface.  The properties like
| sharing of file descriptors are guaranteed.

I confess that my first reaction to this topic was that I could add an
attribute when starting a thread, and then use existing code (pthreads)
and just take advantage of the non-fd-sharing.

Pseudo code: (some of the if's are clearly ifdef)

  if linux add_noshare_to_attributes
  for (;;) {
    fd = listen();
    start_thread(fd)
    if linux clode fd
  }

Clearly that isn't what's needed, I would probably define a
start_service_and_close_fd_ifUcan macro/procedure. When this is stable
and 2.6 is closer to production quality I will probably modify a few
applications to see what benefits might be available.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
  2003-10-09 18:12                         ` bill davidsen
@ 2003-10-10  4:39                           ` Jamie Lokier
  0 siblings, 0 replies; 128+ messages in thread
From: Jamie Lokier @ 2003-10-10  4:39 UTC (permalink / raw)
  To: bill davidsen; +Cc: linux-kernel

bill davidsen wrote:
> Your base point that resources shouldn't be shared needlessly is
> correct, or course.

On that theme, non-shared fd tables are slightly faster than shared
due to (a) reduced cache line transfers between CPUs; (b) fewer fds
between tables reduces the time to search for a free fd when something
is opened.

I'm sure it's a tiny effect, but it is there.

-- Jamie

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Here is a case that proves my previous position wrong regurading CLONE_THREAD and CLONE_FILES
  2003-10-08  0:41                     ` Robert White
  2003-10-08  0:54                       ` Linus Torvalds
  2003-10-09 17:59                       ` bill davidsen
@ 2003-10-11  3:02                       ` Robert White
  2003-10-11  3:48                         ` viro
  2003-10-12 11:41                         ` Jamie Lokier
  2 siblings, 2 replies; 128+ messages in thread
From: Robert White @ 2003-10-11  3:02 UTC (permalink / raw)
  To: 'Robert White', 'Linus Torvalds'
  Cc: 'Albert Cahalan', 'Ulrich Drepper',
	'Mikael Pettersson', 'Kernel Mailing List'

For those who care:

Earlier I was phrasing arguments for requiring that the CLONE_THREAD
argument to clone() require implication of CLONE_FILES.  I officially recant
those arguments.  In those prior posts I asked for a specific demonstrable
case against this requirement.  Having found one myself, I provide it here
so that if the question comes up again from other quarters it can be
answered (or killed 8-) more easily.

[This post is significantly aimed at persons searching the mailing list so
please forgive some of the more elementary observations.  Near the end I do
a compare and contrast of the kernel provided clone() feature to the pthread
and java task paradigms for those who got here via the words "thread" or
"task".]

The class of applications that contain "safe interpreters" makes a classic
example case in favor of threads with disjoint file descriptor lists being
desirable and, as scale increases, necessary.  This class of applications
includes the multi-player and massively multi-player games (muds, mushes,
etc) at one end and, at the other end, things like the "TCL Browser Plugin"
or any application which would want to safely and efficiently allow
connected individuals/entities to "script" behaviors.

[I will hereafter use simple MUD style game paradigms for the examples.]

It should be taken as read that the use of the CLONE_THREAD flag is
desirable.  The multi-session game (etc) gains no benefit from its disuse
and the administration and maintenance of the server is harmed by its
absence.  The client sessions in each thread cease to have meaning or
function if the core gaming facility ceases to function.  Likewise separate
external termination of a client/constituent process joined with only
CLONE_VM (etc) but not CLONE_THREAD would almost certainly lead to a
catastrophic loss of internal consistency.  That is, if the threads don't
share data then they really should be separate programs; if they do, then
individually terminating one of the constituents has a high likely hood of
leaving damage in that shared data pool.

The efficiency argument:

In any scripting environment, the core (bound) executable code provides a
series of scripting primitives.  One such primitive might be "Say".  As the
number of participants rises, the complexity of the actions of a primitive
must fall for the performance to remain practical.  

So it becomes desirable to approach linear, OS level complexity for a given
primitive.  If file handles to pipes (etc) are the chosen way to send the
statement from the thread entity to the core logic, it would be ideal to be
able to write the "say" primitive as simply as

void cmd_say(char *text) { write(X,text,strlen(text)); }

If the file descriptor tables are unified (all threads share one table) then
the "X" would have to be a non-trivial function ThisThreadsSayFD() which
would bear the burden of traversing some sort of lookup table, and probably
checking access lists.  At a minimum there would need to be some kind of
thread-specific variable support (a la POSIX).  At its worst, this would
lead to incremental cost increases for each attached instance.  This lookup
would, of necessity, cost several times to several orders of magnitude more
effort/CPU/time than the actual intended write operation.  That
magnification of cost would move the cap on concurrency down rather
significantly.

This late lookup is particular to the case of a scripting engine.  A fully
bound executable with no scripting behavior would (likely) already be
carrying its variables in its active context as arguments.  Current
technologies for a scripting environment require typically much larger
context structures.  (see Tcl_CreateInterp() et al)

The technique of coercing file descriptors into specific values is already
well known and understood.  Every time a shell pipeline is constructed work
happens between the fork() and exec() calls which close() and dup() file
handles into specific values.  [e.g. the establishment of standard input as
FD 0 and so on should be understood, and is documented elsewhere.]

If similar techniques are used in the establishment of each cloned thread
one can pay the cost to find/coerce the correct file descriptor for each/any
task exactly once.  This nets linear cost both during thread creation and
scripting primitive execution.

So, if at creation time in this example, the connection to the client is
coerced into descriptor 0 and the conversation pipe to descriptor 1, the
above cmd_say() function can now be written to run safely in linear time
using the constant value 1 for X.

void cmd_say(char *text) { write(X,text,strlen(text)); }

Of course the efficiency argument would be incomplete without asking why use
descriptors at all?  It is clear that if you have your VM space in common,
it would be faster to send pointers to buffers around instead of writing to
files.  A rational game running in a single threaded process would likely do
that very thing.  But an extensible game with multiple servers or
distributed clients would eventually come to these questions.  Since the
discussion is about the file descriptor table being unique amongst threads,
the simple model used is valuable.

The security argument:

Security is (generally) more important than efficiency when dealing with
scriptable interfaces.  It is reasonably possible to write a program which
does no harm.  As soon as you allow unknown or un-trusted parties access to
scripting features you increase your vulnerability, usually by a huge
amount.  Even in the absence of malice it is usual to want to grant
different users different kinds of access.

Consider the game again.  The core engine will need to have open connections
to the database files or services, the network listener, and so forth.
Administrative users will need access to debug logs, overrides, and
controls.  Normal users, and their scripts, should have no such access.

By spawning your threads without the CLONE_FILES flag, you can partition the
normal users away from these system level accesses via the simple expedient
of closing the file handles in the new thread.  This could largely prevent
script based fishing expeditions (e.g. calling scripting primitives with
likely guesses about other entity tags representing file descriptors) and is
particularly applicable to the more complex scripting or virtual machine
environments.

If all your threads share the same file descriptor table, then you must be
able to "prove" your GetTheRightDiscriptor() function for each possible
fetched descriptor.  The function has to be able to return the right thing
without ever returning the wrong thing.  That is expensive and complex, and
complexity leads to error.

It is easier to "prove" that your ListenFoNewClients() thread starts before
the database and administrative channels are even open (etc) and that your
CreateNewClientThread() routine closes the few common resources the Listen
thread needed before it gives control to the actual script/client.

Closing files out in the new thread increases safety and actually improves
performance.

(Think about how much nicer and safer email would be on windows if Outlook
did this, didn't share descriptors, and its scripting environment didn't
include an open() call, or at least its open() *ALWAYS* asked the operator
if the open was ok...)

====

Linux Kernel Threads, versus POSIX Threads, Java tasks, et al.

Some of you reading this are probably asking yourself WTF I am talking
about, and you just want to know if you can do some particular thing in your
threaded program.  The answer is that if you are using pthread_create() in
your program, the above discussion probably doesn't directly apply to you at
any level that you need to care about.

Your answer lies in these three statements:
1) The Linux Kernel does not provide POSIX style thread support.
2) The Linux Kernel does provide everything necessary for the libpthread
library to provide POSIX style thread support.
3) The Linux Kernel (also) provides features for decidedly non POSIX style
threads.

If you substitute "Java" or "ADA" and the appropriate libraries or runtimes
in the above you get the same basic truths, and it would be a mistake to
wish otherwise.

The POSIX threading interface is, when you think about it, a detailed
description of a set of features and facilities that work together a certain
way.  It forms a set of promises about what you can expect the system to do,
look like, and do for you, within a single program.  Its scope is naturally
not extendable to an entire OS or platform.  That may not seem obvious to
you, but consider these assertions made by the POSIX standard.

1) There is a "main thread".
2) When the main thread exits all the threads are canceled.
3) You can create a "detached" thread that can not be pthread_joined().
4) [Detached threads are (surprisingly to some) subject to rule 2]

If you were to try to apply the four rules above to an entire operating
system, there could only be one main thread in the whole system.  (Some
might argue that init fills this role in GNU/Linux but) That would preclude
the individual pthread programs from having their own main thread and
reaping the benefits of both detached threads and application termination
semantics.

Further, and still worse, consider that when you call pthread_create() it
does far more than just start a process or program.  It must create and set
up the data structures on which cancellation, thread specific data, cleanup
push/pop, and so on are based.  pthread_exit() must likewise undo all that.
If the kernel were asked to do this work, then these structures would be
both slow and semi-public.  Neither property would be good for your program
no the system as a whole.

All of the above would also be true for every mutex and condition variable
too.

So when you see pthread_[anything] you are relying on the library to "do the
right thing for you" in providing that consistent interface.  When you
consider how bad native pthread support is in Windows, and then how much
better it is in cygwin, you see just how bad it can be to try to merge the
application-level pthread paradigm with the operating system core functions.

This is identical to how the Java Virtual Machine is in charge of doing the
right thing for a java program etc.


So what does the kernel provide and what is all this talk of threads?

[begin quick history lesson]

If you take a quick trample through the *NIX history you will find two
system calls very close to its heart.  fork() and exec().  These two calls
share between them the tasks necessary to invoke a program.  The actual
genius is the fact that they split this work.  The horror is how expensive
fork() could be, and that led to vfork().

In reverse order, exec() basically means "I wish to suicide in favor of this
other program."  When you exec() your memory and stack space are wiped out
and replaced with the image of the new program to run.  That program does
inherit all of your other traits (process number, permissions, most or all
of your open files, etc) but everything in the process data and code space
is gone.  (This last bit is, incidentally, why we have "environment
variables", so that some common data may survive.)

With only exec() you would never be able to have more than one program
running.  Enter fork(), which takes the entire process and copies it.  Where
there was one process there are now two identical processes.  The new
process, the child, the copy, would then tweak a few file handles around etc
and then call exec().

Since the first program was copied you needed to have as much memory free as
the program was already using, that could get very pricy.  If the fork()ing
program was larger than available memory it could be impossible.  And all
this was often being done just so that the new copy could be discarded a few
instructions later.

Enter vfork(). This "virtual fork" call didn't actually copy the process
memory image, it just acted like it had to span the tiny bit of time between
the vfork() and the exec() calls.  This saved tremendous amount of space and
time.

And then time moved on and the hardware got better and the software
paradigms became more expansive... 

[end quick history lesson]

Linux provides clone() "in place of" the standard fork() and vfork().  I use
the quotes because if you look in the code you will *actually* see the
fork.c file and entry.S file.  There are entry points for each of sys_clone,
sys_fork, and sys_vfork and they all eventually pile back into the same code
calling do_fork() with different arguments.  It's just easier to take at one
gulp if you think of clone() as the new generic thing and fork() and vfork()
special cases.  Have I lost you yet?

The real inspired part of clone() is that you get to choose what gets copied
and what just gets shared between the old and the new process.  If you look
in your linux source directory for include/linux/sched.h you will see there
is a whole set of values that can be passed into clone to tell it how to
slice/copy (e.g. clone) the new task from the old.  By artfully combining
the flags you can do all sorts of interesting things when cloning yourself.

At one end you can get the original fork() and at the other end you can get
the tightly intermeshed entities necessary for implementing pthreads (and
Java tasks and such).

Now, if you run a pthread based program on a 2.4 kernel, and do a "ps -ef"
you will see the same program repeated as a bunch of processes because of
the way clone is called for each thread you (or the library) creates.  The
weird thing is that because each thread is a separate process the outside
world sees things it doesn't need to see and can do things to individual
threads it kind of ought not to be able to do.  This is how you could
occasionally exit or kill a pthread based program and end up with tidbits of
it (one or two processes) left behind.

The 2.5 kernel adds the CLONE_THREAD flag to the list of clone available
options.  The flag lets the application programmer (or in this case the
pthreads library programmer) essentially say "no really, these tightly
interwoven and interdependent entities can not live away from their
siblings.  Treat them as one process."

When you run a pthreads based program on a 2.5 or later kernel AND you are
using a version of libpthread that knows about/uses CLONE_THREAD you will
see just one listing for the program (unless you ask ps to show you all the
parts by using -m).  Indeed the kernel keeps the parts more intimately bound
which makes a bunch of things better including, but not limited to, better
management and exit strategies.

=====

The above may be reproduced or referenced for any purpose except for suing
me or my employer.

Rob.



^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Here is a case that proves my previous position wrong regurading CLONE_THREAD and CLONE_FILES
  2003-10-11  3:02                       ` Here is a case that proves my previous position wrong regurading CLONE_THREAD and CLONE_FILES Robert White
@ 2003-10-11  3:48                         ` viro
  2003-10-12 11:41                         ` Jamie Lokier
  1 sibling, 0 replies; 128+ messages in thread
From: viro @ 2003-10-11  3:48 UTC (permalink / raw)
  To: Robert White
  Cc: 'Linus Torvalds', 'Albert Cahalan',
	'Ulrich Drepper', 'Mikael Pettersson',
	'Kernel Mailing List'

On Fri, Oct 10, 2003 at 08:02:49PM -0700, Robert White wrote:
> For those who care:
> 
> Earlier I was phrasing arguments for requiring that the CLONE_THREAD
> argument to clone() require implication of CLONE_FILES.  I officially recant
> those arguments.  In those prior posts I asked for a specific demonstrable
> case against this requirement.  Having found one myself, I provide it here
> so that if the question comes up again from other quarters it can be
> answered (or killed 8-) more easily.
> 
> [This post is significantly aimed at persons searching the mailing list so
> please forgive some of the more elementary observations.  Near the end I do
> a compare and contrast of the kernel provided clone() feature to the pthread
> and java task paradigms for those who got here via the words "thread" or
> "task".]

[snip]

One note: non-shared descriptor table with shared VM (or vice versa) is
not unique to Linux.  *BSD have a syscall very similar in spirit to clone(2)
- rfork(2).  So does Plan 9, where that beast had originated.

IOW, that model is actually *absent* only in SysV - arguably, the least
Unix-like of Unix clones...

{Free,Open,Net}BSD rfork() differs from clone() only in arguments.  Plan 9
one always gives task-private stack - even if VM is otherwise shared.

BTW, there's a bunch of syscalls that require careful userland code if
descriptors _are_ shared - select() is a good example, since we get the
answer in terms of descriptor table at the moment of call.  Having one
thread put descriptor 42 into set, call select and return after another
thread does close(42); or dup2(fd, 42)...

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Here is a case that proves my previous position wrong regurading CLONE_THREAD and CLONE_FILES
  2003-10-11  3:02                       ` Here is a case that proves my previous position wrong regurading CLONE_THREAD and CLONE_FILES Robert White
  2003-10-11  3:48                         ` viro
@ 2003-10-12 11:41                         ` Jamie Lokier
  1 sibling, 0 replies; 128+ messages in thread
From: Jamie Lokier @ 2003-10-12 11:41 UTC (permalink / raw)
  To: Robert White
  Cc: 'Linus Torvalds', 'Albert Cahalan',
	'Ulrich Drepper', 'Mikael Pettersson',
	'Kernel Mailing List'

Robert White wrote:
> The class of applications that contain "safe interpreters"

That's a fine long exposition you have there, but

> If the file descriptor tables are unified (all threads share one table) then
> the "X" would have to be a non-trivial function ThisThreadsSayFD() which
> would bear the burden of traversing some sort of lookup table, and probably
> checking access lists.  At a minimum there would need to be some kind of
> thread-specific variable support (a la POSIX).

Thread-specific variables take somewhere between zero and a few clock
cycles, when implemented properly (as they are now on Linux).

Also, it is nothing compared with the thread-specific interpreter
context that you already have running...

> By spawning your threads without the CLONE_FILES flag, you can partition the
> normal users away from these system level accesses via the simple expedient
> of closing the file handles in the new thread.  This could largely prevent
> script based fishing expeditions (e.g. calling scripting primitives with
> likely guesses about other entity tags representing file descriptors) and is
> particularly applicable to the more complex scripting or virtual machine
> environments.
> 
> If all your threads share the same file descriptor table, then you must be
> able to "prove" your GetTheRightDiscriptor() function for each possible
> fetched descriptor.  The function has to be able to return the right thing
> without ever returning the wrong thing.  That is expensive and complex, and
> complexity leads to error.

It's at least as difficult to prove that the script can't access other
threads' memory, which is a bigger weak point.  If you need proper
security isolation, you're going to need to _not_ use CLONE_VM.

That's not to say that separate file tables with CLONE_VM aren't
useful; they are.  But in my opionion efficiency of looking up an fd
number and interpreter security isolation aren't serious reasons.

-- Jamie




> 
> It is easier to "prove" that your ListenFoNewClients() thread starts before
> the database and administrative channels are even open (etc) and that your
> CreateNewClientThread() routine closes the few common resources the Listen
> thread needed before it gives control to the actual script/client.
> 
> Closing files out in the new thread increases safety and actually improves
> performance.
> 
> (Think about how much nicer and safer email would be on windows if Outlook
> did this, didn't share descriptors, and its scripting environment didn't
> include an open() call, or at least its open() *ALWAYS* asked the operator
> if the open was ok...)
> 
> ====
> 
> Linux Kernel Threads, versus POSIX Threads, Java tasks, et al.
> 
> Some of you reading this are probably asking yourself WTF I am talking
> about, and you just want to know if you can do some particular thing in your
> threaded program.  The answer is that if you are using pthread_create() in
> your program, the above discussion probably doesn't directly apply to you at
> any level that you need to care about.
> 
> Your answer lies in these three statements:
> 1) The Linux Kernel does not provide POSIX style thread support.
> 2) The Linux Kernel does provide everything necessary for the libpthread
> library to provide POSIX style thread support.
> 3) The Linux Kernel (also) provides features for decidedly non POSIX style
> threads.
> 
> If you substitute "Java" or "ADA" and the appropriate libraries or runtimes
> in the above you get the same basic truths, and it would be a mistake to
> wish otherwise.
> 
> The POSIX threading interface is, when you think about it, a detailed
> description of a set of features and facilities that work together a certain
> way.  It forms a set of promises about what you can expect the system to do,
> look like, and do for you, within a single program.  Its scope is naturally
> not extendable to an entire OS or platform.  That may not seem obvious to
> you, but consider these assertions made by the POSIX standard.
> 
> 1) There is a "main thread".
> 2) When the main thread exits all the threads are canceled.
> 3) You can create a "detached" thread that can not be pthread_joined().
> 4) [Detached threads are (surprisingly to some) subject to rule 2]
> 
> If you were to try to apply the four rules above to an entire operating
> system, there could only be one main thread in the whole system.  (Some
> might argue that init fills this role in GNU/Linux but) That would preclude
> the individual pthread programs from having their own main thread and
> reaping the benefits of both detached threads and application termination
> semantics.
> 
> Further, and still worse, consider that when you call pthread_create() it
> does far more than just start a process or program.  It must create and set
> up the data structures on which cancellation, thread specific data, cleanup
> push/pop, and so on are based.  pthread_exit() must likewise undo all that.
> If the kernel were asked to do this work, then these structures would be
> both slow and semi-public.  Neither property would be good for your program
> no the system as a whole.
> 
> All of the above would also be true for every mutex and condition variable
> too.
> 
> So when you see pthread_[anything] you are relying on the library to "do the
> right thing for you" in providing that consistent interface.  When you
> consider how bad native pthread support is in Windows, and then how much
> better it is in cygwin, you see just how bad it can be to try to merge the
> application-level pthread paradigm with the operating system core functions.
> 
> This is identical to how the Java Virtual Machine is in charge of doing the
> right thing for a java program etc.
> 
> 
> So what does the kernel provide and what is all this talk of threads?
> 
> [begin quick history lesson]
> 
> If you take a quick trample through the *NIX history you will find two
> system calls very close to its heart.  fork() and exec().  These two calls
> share between them the tasks necessary to invoke a program.  The actual
> genius is the fact that they split this work.  The horror is how expensive
> fork() could be, and that led to vfork().
> 
> In reverse order, exec() basically means "I wish to suicide in favor of this
> other program."  When you exec() your memory and stack space are wiped out
> and replaced with the image of the new program to run.  That program does
> inherit all of your other traits (process number, permissions, most or all
> of your open files, etc) but everything in the process data and code space
> is gone.  (This last bit is, incidentally, why we have "environment
> variables", so that some common data may survive.)
> 
> With only exec() you would never be able to have more than one program
> running.  Enter fork(), which takes the entire process and copies it.  Where
> there was one process there are now two identical processes.  The new
> process, the child, the copy, would then tweak a few file handles around etc
> and then call exec().
> 
> Since the first program was copied you needed to have as much memory free as
> the program was already using, that could get very pricy.  If the fork()ing
> program was larger than available memory it could be impossible.  And all
> this was often being done just so that the new copy could be discarded a few
> instructions later.
> 
> Enter vfork(). This "virtual fork" call didn't actually copy the process
> memory image, it just acted like it had to span the tiny bit of time between
> the vfork() and the exec() calls.  This saved tremendous amount of space and
> time.
> 
> And then time moved on and the hardware got better and the software
> paradigms became more expansive... 
> 
> [end quick history lesson]
> 
> Linux provides clone() "in place of" the standard fork() and vfork().  I use
> the quotes because if you look in the code you will *actually* see the
> fork.c file and entry.S file.  There are entry points for each of sys_clone,
> sys_fork, and sys_vfork and they all eventually pile back into the same code
> calling do_fork() with different arguments.  It's just easier to take at one
> gulp if you think of clone() as the new generic thing and fork() and vfork()
> special cases.  Have I lost you yet?
> 
> The real inspired part of clone() is that you get to choose what gets copied
> and what just gets shared between the old and the new process.  If you look
> in your linux source directory for include/linux/sched.h you will see there
> is a whole set of values that can be passed into clone to tell it how to
> slice/copy (e.g. clone) the new task from the old.  By artfully combining
> the flags you can do all sorts of interesting things when cloning yourself.
> 
> At one end you can get the original fork() and at the other end you can get
> the tightly intermeshed entities necessary for implementing pthreads (and
> Java tasks and such).
> 
> Now, if you run a pthread based program on a 2.4 kernel, and do a "ps -ef"
> you will see the same program repeated as a bunch of processes because of
> the way clone is called for each thread you (or the library) creates.  The
> weird thing is that because each thread is a separate process the outside
> world sees things it doesn't need to see and can do things to individual
> threads it kind of ought not to be able to do.  This is how you could
> occasionally exit or kill a pthread based program and end up with tidbits of
> it (one or two processes) left behind.
> 
> The 2.5 kernel adds the CLONE_THREAD flag to the list of clone available
> options.  The flag lets the application programmer (or in this case the
> pthreads library programmer) essentially say "no really, these tightly
> interwoven and interdependent entities can not live away from their
> siblings.  Treat them as one process."
> 
> When you run a pthreads based program on a 2.5 or later kernel AND you are
> using a version of libpthread that knows about/uses CLONE_THREAD you will
> see just one listing for the program (unless you ask ps to show you all the
> parts by using -m).  Indeed the kernel keeps the parts more intimately bound
> which makes a bunch of things better including, but not limited to, better
> management and exit strategies.
> 
> =====
> 
> The above may be reproduced or referenced for any purpose except for suing
> me or my employer.
> 
> Rob.
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-10-03  3:51 ` Jason Munro
  2003-10-06  3:05   ` bill davidsen
@ 2003-10-09 18:44   ` bill davidsen
  1 sibling, 0 replies; 128+ messages in thread
From: bill davidsen @ 2003-10-09 18:44 UTC (permalink / raw)
  To: linux-kernel

In article <ddcbaa61f5ab6ec90c71a70bb3990b49@stdbev.com>,
Jason Munro <jason@stdbev.com> wrote:
| On October 2, 7:07 pm Nick Piggin <piggin@cyberone.com.au> wrote:
| >
| > Pedro Larroy wrote:
| >
| > > On Thu, Oct 02, 2003 at 01:05:36PM +1000, Nick Piggin wrote:
| > > I'm afraid this selection criteria leads to a scheduler that isn't
| > > predictable for situations that aren't the ones for which is tuned to
| > > work. Of course I may be wrong, but to me, seems that saying
| > > explicitly which tasks are interactive sounds better.
| > >
| >
| > Have a look at my scheduler if you like. It won't estimate interactivity
| > but it works quite well if you nice -10 your X server. Ie. explicitly
| > state which process should be favoured.
| > http://www.kerneltrap.org/~npiggin/v15a/
| 
| I don't know much about kernel internals but of the 2.5 and 2.6 kernels I
| have tried, 2.6.0-test6 is by far the best on the desktop for my use (xmms,
| vmware, firebird, loads of other apps). With this patch it's better still.
| Before patching simple things like ls or ps have an annoying slowness while
| under a moderate/heavy load. For the most part things are fine but after
| patching commands respond more quickly. This is the first time for me a
| 2.5+ kernel has been responsive enough to use on a daily basis.

I really like my "np15a" patch, but it doesn't seem to play well with
preempt in terms of performance. Stability is fine so far.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-10-03  3:51 ` Jason Munro
@ 2003-10-06  3:05   ` bill davidsen
  2003-10-09 18:44   ` bill davidsen
  1 sibling, 0 replies; 128+ messages in thread
From: bill davidsen @ 2003-10-06  3:05 UTC (permalink / raw)
  To: linux-kernel

In article <ddcbaa61f5ab6ec90c71a70bb3990b49@stdbev.com>,
Jason Munro <jason@stdbev.com> wrote:
| On October 2, 7:07 pm Nick Piggin <piggin@cyberone.com.au> wrote:
| >
| > Pedro Larroy wrote:
| >
| > > On Thu, Oct 02, 2003 at 01:05:36PM +1000, Nick Piggin wrote:
| > > I'm afraid this selection criteria leads to a scheduler that isn't
| > > predictable for situations that aren't the ones for which is tuned to
| > > work. Of course I may be wrong, but to me, seems that saying
| > > explicitly which tasks are interactive sounds better.
| > >
| >
| > Have a look at my scheduler if you like. It won't estimate interactivity
| > but it works quite well if you nice -10 your X server. Ie. explicitly
| > state which process should be favoured.
| > http://www.kerneltrap.org/~npiggin/v15a/
| 
| I don't know much about kernel internals but of the 2.5 and 2.6 kernels I
| have tried, 2.6.0-test6 is by far the best on the desktop for my use (xmms,
| vmware, firebird, loads of other apps). With this patch it's better still.
| Before patching simple things like ls or ps have an annoying slowness while
| under a moderate/heavy load. For the most part things are fine but after
| patching commands respond more quickly. This is the first time for me a
| 2.5+ kernel has been responsive enough to use on a daily basis.

I would like to add my thoughts that test6-np15a is the winner for the
things I do. I can live with a sound skip (I haven't seen any, but it's
not my test app), I really want my typing to echo, to click on a header
in Kmail and see the text, to have ls works, etc. Nick has given me that
far more than test6 plain or with -mm flavor.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
@ 2003-10-03  3:51 ` Jason Munro
  2003-10-06  3:05   ` bill davidsen
  2003-10-09 18:44   ` bill davidsen
  0 siblings, 2 replies; 128+ messages in thread
From: Jason Munro @ 2003-10-03  3:51 UTC (permalink / raw)
  To: linux-kernel

On October 2, 7:07 pm Nick Piggin <piggin@cyberone.com.au> wrote:
>
> Pedro Larroy wrote:
>
> > On Thu, Oct 02, 2003 at 01:05:36PM +1000, Nick Piggin wrote:
> > I'm afraid this selection criteria leads to a scheduler that isn't
> > predictable for situations that aren't the ones for which is tuned to
> > work. Of course I may be wrong, but to me, seems that saying
> > explicitly which tasks are interactive sounds better.
> >
>
> Have a look at my scheduler if you like. It won't estimate interactivity
> but it works quite well if you nice -10 your X server. Ie. explicitly
> state which process should be favoured.
> http://www.kerneltrap.org/~npiggin/v15a/

I don't know much about kernel internals but of the 2.5 and 2.6 kernels I
have tried, 2.6.0-test6 is by far the best on the desktop for my use (xmms,
vmware, firebird, loads of other apps). With this patch it's better still.
Before patching simple things like ls or ps have an annoying slowness while
under a moderate/heavy load. For the most part things are fine but after
patching commands respond more quickly. This is the first time for me a
2.5+ kernel has been responsive enough to use on a daily basis.

Thanks everyone for the great work!

\_____ Jason Munro ________________________
 \_____ jason@stdbev.com ___________________
  \_____ #hastymail at irc.freenode.net _____
   \_____ http://hastymail.sourceforge.net ___

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-30 15:17       ` Bill Davidsen
@ 2003-10-01  9:08         ` Jörn Engel
  0 siblings, 0 replies; 128+ messages in thread
From: Jörn Engel @ 2003-10-01  9:08 UTC (permalink / raw)
  To: Bill Davidsen; +Cc: linux-kernel

On Tue, 30 September 2003 11:17:51 -0400, Bill Davidsen wrote:
> On Tue, 30 Sep 2003, [iso-8859-1] J?rn Engel wrote:
> > 
> > How is this better than adding "-H", as Jamie suggested?
> 
> I didn't see that in Linus' post, and still don't. I suspect you're
> thinking of some post which came later. Linus asked for ideas, I supplied
> one, sorry it offends you.

Ok, my bad.

I wasn't offended, just curious, which one of the suggestions would be
the best.  Jamie's idea of using -H looks better to me than yours, but
maybe I have missed something, so I asked.

For some reason, I often miss the tone.  Any emotional stuff in my
posts is unintended, useless and should be removed before sending.
Sorry!

Jörn

PS: So, does your idea have advantages over Jamie's that I missed?

-- 
"Translations are and will always be problematic. They inflict violence 
upon two languages." (translation from German)

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-30 10:42     ` Jörn Engel
@ 2003-09-30 15:17       ` Bill Davidsen
  2003-10-01  9:08         ` Jörn Engel
  0 siblings, 1 reply; 128+ messages in thread
From: Bill Davidsen @ 2003-09-30 15:17 UTC (permalink / raw)
  To: Jörn Engel; +Cc: linux-kernel

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=US-ASCII, Size: 1385 bytes --]

On Tue, 30 Sep 2003, [iso-8859-1] Jörn Engel wrote:

> On Mon, 29 September 2003 19:19:30 +0000, bill davidsen wrote:
> > In article <Pine.LNX.4.44.0309281035370.6307-100000@home.osdl.org>,
> > Linus Torvalds  <torvalds@osdl.org> wrote:
> > 
> > | Interesting. I'm pretty sure I did a "make allyesconfig" just before the
> > | test6 release, so apparently x86 includes it indirectly through some path, 
> > | and so it only shows up on m68k and arm?
> > | 
> > | This, btw, is a pretty common thing. I wonder what we could do to make 
> > | sure that different architectures wouldn't have so different include file 
> > | structures. It's happened _way_ too often.
> > | 
> > | Any ideas?
> > 
> > If CPU cycles are no object the include names and order can be picked
> > out of the preprocessor output, add "-E" to the gcc call, pick only the
> > lines starting with "1" and a header name, save in a text file. The
> > problem is that config option (including arch) change the output, so
> > it's only useful as a rough check.
> 
> How is this better than adding "-H", as Jamie suggested?

I didn't see that in Linus' post, and still don't. I suspect you're
thinking of some post which came later. Linus asked for ideas, I supplied
one, sorry it offends you.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-29 19:19   ` bill davidsen
@ 2003-09-30 10:42     ` Jörn Engel
  2003-09-30 15:17       ` Bill Davidsen
  0 siblings, 1 reply; 128+ messages in thread
From: Jörn Engel @ 2003-09-30 10:42 UTC (permalink / raw)
  To: bill davidsen; +Cc: linux-kernel

On Mon, 29 September 2003 19:19:30 +0000, bill davidsen wrote:
> In article <Pine.LNX.4.44.0309281035370.6307-100000@home.osdl.org>,
> Linus Torvalds  <torvalds@osdl.org> wrote:
> 
> | Interesting. I'm pretty sure I did a "make allyesconfig" just before the
> | test6 release, so apparently x86 includes it indirectly through some path, 
> | and so it only shows up on m68k and arm?
> | 
> | This, btw, is a pretty common thing. I wonder what we could do to make 
> | sure that different architectures wouldn't have so different include file 
> | structures. It's happened _way_ too often.
> | 
> | Any ideas?
> 
> If CPU cycles are no object the include names and order can be picked
> out of the preprocessor output, add "-E" to the gcc call, pick only the
> lines starting with "1" and a header name, save in a text file. The
> problem is that config option (including arch) change the output, so
> it's only useful as a rough check.

How is this better than adding "-H", as Jamie suggested?

> Don't know if this is what you wanted, it does allow the comparison
> between arch's. Oh, it also shows that some headers are used a lot more
> than they need be, a few more ifdef's in the low level header files
> could reduce filesystem thrashing during a build. Some folks have
> machines which don't keep everything in memory :-(

How do you find the correct places to prune include lines?

Jörn

-- 
A defeated army first battles and then seeks victory.
-- Sun Tzu

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-29 10:08       ` Russell King
@ 2003-09-29 19:19         ` Anton Blanchard
  0 siblings, 0 replies; 128+ messages in thread
From: Anton Blanchard @ 2003-09-29 19:19 UTC (permalink / raw)
  To: Linux Kernel Development


> I can confirm that no mail was received from the mail alias for the week
> including September 18th.  Maybe the mail about sched_clock() never made
> it to the alias in the first place?

I got it just fine:

>From akpm@osdl.org  Thu Sep 18 20:09:05 2003
Date:   Thu, 18 Sep 2003 12:45:52 -0700
From: Andrew Morton <akpm@osdl.org>
Subject: sched_clock implementation
Message-Id: <20030918124552.7eb34d6a.akpm@osdl.org>
 
I'll be merging Ingo & Con's CPOU scheduler changes into Linus's tree
soon.
 
It does require that the architecture provides a new timing function:

...

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28 17:37 ` Linus Torvalds
  2003-09-28 18:46   ` Sam Ravnborg
  2003-09-28 19:28   ` Russell King
@ 2003-09-29 19:19   ` bill davidsen
  2003-09-30 10:42     ` Jörn Engel
  2 siblings, 1 reply; 128+ messages in thread
From: bill davidsen @ 2003-09-29 19:19 UTC (permalink / raw)
  To: linux-kernel

In article <Pine.LNX.4.44.0309281035370.6307-100000@home.osdl.org>,
Linus Torvalds  <torvalds@osdl.org> wrote:

| Interesting. I'm pretty sure I did a "make allyesconfig" just before the
| test6 release, so apparently x86 includes it indirectly through some path, 
| and so it only shows up on m68k and arm?
| 
| This, btw, is a pretty common thing. I wonder what we could do to make 
| sure that different architectures wouldn't have so different include file 
| structures. It's happened _way_ too often.
| 
| Any ideas?

If CPU cycles are no object the include names and order can be picked
out of the preprocessor output, add "-E" to the gcc call, pick only the
lines starting with "1" and a header name, save in a text file. The
problem is that config option (including arch) change the output, so
it's only useful as a rough check.

It does run fast enough so that allyes, allno, and allmod configs take a
very short time, so it can be used for "find some of the problems."

Don't know if this is what you wanted, it does allow the comparison
between arch's. Oh, it also shows that some headers are used a lot more
than they need be, a few more ifdef's in the low level header files
could reduce filesystem thrashing during a build. Some folks have
machines which don't keep everything in memory :-(

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-29 15:08         ` Chris Friesen
@ 2003-09-29 15:14           ` Geert Uytterhoeven
  0 siblings, 0 replies; 128+ messages in thread
From: Geert Uytterhoeven @ 2003-09-29 15:14 UTC (permalink / raw)
  To: Chris Friesen
  Cc: Russell King, Jörn Engel, Linus Torvalds,
	Bernardo Innocenti, Kernel Mailing List, Sam Ravnborg

On Mon, 29 Sep 2003, Chris Friesen wrote:
> Russell King wrote:
> > If a header has something like these:
> > 
> > struct my_headers_struct {
> > 	struct task_struct *tsk;
> > };
> > 
> > void my_function(struct task_struct *tsk);
> > 
> > and gcc warns that "struct task_struct" has not been declared, please
> > don't think about adding another header.  Just declare the structure
> > in the header file which needs it like this:
> > 
> > struct task_struct;
> 
> If I do that, make a change to task_struct, then run make, will the file 
> get rebuilt?

No. But using that definition all you can do (without warnings) is passing
pointers to the struct around, which is OK.

If you want to play with the internals of the structure, you have to include
the right header file anyway.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28 19:42       ` Russell King
  2003-09-28 20:00         ` Jörn Engel
@ 2003-09-29 15:08         ` Chris Friesen
  2003-09-29 15:14           ` Geert Uytterhoeven
  1 sibling, 1 reply; 128+ messages in thread
From: Chris Friesen @ 2003-09-29 15:08 UTC (permalink / raw)
  To: Russell King
  Cc: Jörn Engel, Linus Torvalds, Geert Uytterhoeven,
	Bernardo Innocenti, Kernel Mailing List, Sam Ravnborg

Russell King wrote:

> If a header has something like these:
> 
> struct my_headers_struct {
> 	struct task_struct *tsk;
> };
> 
> void my_function(struct task_struct *tsk);
> 
> and gcc warns that "struct task_struct" has not been declared, please
> don't think about adding another header.  Just declare the structure
> in the header file which needs it like this:
> 
> struct task_struct;

If I do that, make a change to task_struct, then run make, will the file 
get rebuilt?

Chris


-- 
Chris Friesen                    | MailStop: 043/33/F10
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-29  9:58     ` Geert Uytterhoeven
@ 2003-09-29 10:08       ` Russell King
  2003-09-29 19:19         ` Anton Blanchard
  0 siblings, 1 reply; 128+ messages in thread
From: Russell King @ 2003-09-29 10:08 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Andrew Morton, oliver, Linus Torvalds, Linux Kernel Development

On Mon, Sep 29, 2003 at 11:58:00AM +0200, Geert Uytterhoeven wrote:
> On Sun, 28 Sep 2003, Andrew Morton wrote:
> > Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > >
> > > There's a new architecture-specific routine sched_clock() to be implemented
> > >  (which was BTW not announced on the secret all-architectures mail alias ;-).
> > 
> > Was too!  On September 18.
> 
> Did someone remove linux-m68k from the alias? I just checked my mail archives,
> and I didn't receive it.

I can confirm that no mail was received from the mail alias for the week
including September 18th.  Maybe the mail about sched_clock() never made
it to the alias in the first place?

-- 
Russell King (rmk@arm.linux.org.uk)	http://www.arm.linux.org.uk/personal/
      Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
      maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                      2.6 Serial core

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28 21:41   ` Andrew Morton
@ 2003-09-29  9:58     ` Geert Uytterhoeven
  2003-09-29 10:08       ` Russell King
  0 siblings, 1 reply; 128+ messages in thread
From: Geert Uytterhoeven @ 2003-09-29  9:58 UTC (permalink / raw)
  To: Andrew Morton; +Cc: oliver, Linus Torvalds, Linux Kernel Development

On Sun, 28 Sep 2003, Andrew Morton wrote:
> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >
> > There's a new architecture-specific routine sched_clock() to be implemented
> >  (which was BTW not announced on the secret all-architectures mail alias ;-).
> 
> Was too!  On September 18.

Did someone remove linux-m68k from the alias? I just checked my mail archives,
and I didn't receive it.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds



^ permalink raw reply	[flat|nested] 128+ messages in thread

* RE: Linux 2.6.0-test6
@ 2003-09-29  9:00 Oliver Pitzeier
  0 siblings, 0 replies; 128+ messages in thread
From: Oliver Pitzeier @ 2003-09-29  9:00 UTC (permalink / raw)
  To: viro, 'Oliver Pitzeier'
  Cc: 'Linus Torvalds', 'Kernel Mailing List'

Hi Viro!

[ ... ]
> > It work's on my Intel machine, but on Alpha, I get this: <snip>
> >   CC      init/version.o
> >   LD      init/built-in.o
> >   LD      .tmp_vmlinux1
> > kernel/built-in.o: In function `try_to_wake_up':
> > kernel/built-in.o(.text+0x438): undefined reference to `sched_clock'
> 
> Add
> unsigned long long default_sched_clock(void)
> {
> 	return (unsigned long long)jiffies * (1000000000 / HZ);
> }
> 
> in kernel/sched.c and
> 
> #define sched_clock default_sched_clock
> 
> in include/asm-alpha/system.h
> 
> FWIW, the former should've been done from the very beginning

[ ... ]

This seems to work!

Thanks!

Best,
 Oliver


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28 19:28   ` Russell King
@ 2003-09-29  8:52     ` Geert Uytterhoeven
  0 siblings, 0 replies; 128+ messages in thread
From: Geert Uytterhoeven @ 2003-09-29  8:52 UTC (permalink / raw)
  To: Russell King; +Cc: Linus Torvalds, Bernardo Innocenti, Kernel Mailing List

On Sun, 28 Sep 2003, Russell King wrote:
> On Sun, Sep 28, 2003 at 10:37:36AM -0700, Linus Torvalds wrote:
> > On Sun, 28 Sep 2003, Geert Uytterhoeven wrote:
> > > On Sat, 27 Sep 2003, Linus Torvalds wrote:
> > > > Bernardo Innocenti:
> > > >   o GCC 3.3.x/3.4 compatiblity fix in include/linux/init.h
> > > 
> > > This change breaks 2.95 for some source files, because <linux/init.h> doesn't
> > > include <linux/compiler.h>. Do you want to have the missing include added to
> > > <linux/init.h>, or to the individual source files that need it?
> > 
> > Interesting. I'm pretty sure I did a "make allyesconfig" just before the
> > test6 release, so apparently x86 includes it indirectly through some path, 
> > and so it only shows up on m68k and arm?
> > 
> > This, btw, is a pretty common thing. I wonder what we could do to make 
> > sure that different architectures wouldn't have so different include file 
> > structures. It's happened _way_ too often.
> > 
> > Any ideas?
> 
> The two files that it showed up in on ARM are fairly simple in nature and
> don't include may headers.  Making the ARM include structure identical to
> x86 wouldn't have removed the problem from ARM.

Same for m68k. The offender was a m68k-specific file (arch/m68k/sun3/sbus.c),
which just included <linux/types.h> and <linux/init.h>, and uses
subsys_initcall().

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28 21:43           ` Tim Schmielau
@ 2003-09-28 21:54             ` Arnaldo Carvalho de Melo
  0 siblings, 0 replies; 128+ messages in thread
From: Arnaldo Carvalho de Melo @ 2003-09-28 21:54 UTC (permalink / raw)
  To: Tim Schmielau
  Cc: Jörn Engel, Linus Torvalds, Geert Uytterhoeven,
	Bernardo Innocenti, Kernel Mailing List, Sam Ravnborg,
	Russell King

Em Sun, Sep 28, 2003 at 11:43:08PM +0200, Tim Schmielau escreveu:
> P.S.: My secret plan is to write a parser or hack sparse to do this for
> both #if and #else branches of conditionals at the same time. This
> however, is a big project, and I don't think of even _starting_ this
> before next year.

Well, I plan to work on a sparse tool that builds a ctags like database from
all the headers, removes the includes and puts the necessary ones, some
spurious cases can happen, as we don't have the best namespace in the world in
our includes, but hey, janitors could handle such a task, fixing the namespace
:-)

- Arnaldo

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28 20:00         ` Jörn Engel
@ 2003-09-28 21:43           ` Tim Schmielau
  2003-09-28 21:54             ` Arnaldo Carvalho de Melo
  0 siblings, 1 reply; 128+ messages in thread
From: Tim Schmielau @ 2003-09-28 21:43 UTC (permalink / raw)
  To: Jörn Engel
  Cc: Linus Torvalds, Geert Uytterhoeven, Bernardo Innocenti,
	Kernel Mailing List, Sam Ravnborg, Russell King

> Ok, how about this:
>
> for each header file {
> 	make header.o
> 1)	if it doesn't build {
> 		print out a warning
> 		continue
> 	}
> 	for each #include line {
> 		remove the #include line
> 		make header.o
> 2)		if it build {
> 			print out a warning
> 		}
> 3)		if there are less than x gcc warnings {
> 			print out a warning
> 		}
> 	}
> }
>
> 1) is my old proposal.  2) is the natural counterpart.  3) could be
> what you want.  If some header is only needed for something like your
> example, we may be able to catch it this way.
>
> Would this work?  Would something else work even better?


Problem is, this depends too much on the specific configuration, and thus
will never be a general solution (will generate false positives and false
negatives). Might be a good start, though.

Tim


P.S.: My secret plan is to write a parser or hack sparse to do this for
both #if and #else branches of conditionals at the same time. This
however, is a big project, and I don't think of even _starting_ this
before next year.


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28 12:52 ` Geert Uytterhoeven
@ 2003-09-28 21:41   ` Andrew Morton
  2003-09-29  9:58     ` Geert Uytterhoeven
  0 siblings, 1 reply; 128+ messages in thread
From: Andrew Morton @ 2003-09-28 21:41 UTC (permalink / raw)
  To: Geert Uytterhoeven; +Cc: oliver, torvalds, linux-kernel

Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> There's a new architecture-specific routine sched_clock() to be implemented
>  (which was BTW not announced on the secret all-architectures mail alias ;-).

Was too!  On September 18.

I considered providing a default implementation, but really, if the
hardware has a higher resolution timer then sched_clock() should use that. 
Providing a HZ-based default would lessen the likelihood of the Alpha
developers doing this properly.


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28 19:42       ` Russell King
@ 2003-09-28 20:00         ` Jörn Engel
  2003-09-28 21:43           ` Tim Schmielau
  2003-09-29 15:08         ` Chris Friesen
  1 sibling, 1 reply; 128+ messages in thread
From: Jörn Engel @ 2003-09-28 20:00 UTC (permalink / raw)
  To: Linus Torvalds, Geert Uytterhoeven, Bernardo Innocenti,
	Kernel Mailing List, Sam Ravnborg, Russell King

On Sun, 28 September 2003 20:42:24 +0100, Russell King wrote:
> 
> I have a bad feeling about this, so I'll make the following comments
> up front before all the reports start rolling in.  It may be a good
> idea to document this somewhere.  (Coding style?)
> 
> If a header has something like these:
> 
> struct my_headers_struct {
> 	struct task_struct *tsk;
> };
> 
> void my_function(struct task_struct *tsk);
> 
> and gcc warns that "struct task_struct" has not been declared, please
> don't think about adding another header.  Just declare the structure
> in the header file which needs it like this:
> 
> struct task_struct;
> 
> and that will prevent the #include maze of 2.4, which resulted in
> everything being rebuilt just because one header file was touched.

Ok, how about this:

for each header file {
	make header.o
1)	if it doesn't build {
		print out a warning
		continue
	}
	for each #include line {
		remove the #include line
		make header.o
2)		if it build {
			print out a warning
		}
3)		if there are less than x gcc warnings {
			print out a warning
		}
	}
}

1) is my old proposal.  2) is the natural counterpart.  3) could be
what you want.  If some header is only needed for something like your
example, we may be able to catch it this way.

Would this work?  Would something else work even better?

Jörn

-- 
Rules of Optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet.
-- M.A. Jackson 

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28 19:31       ` Sam Ravnborg
@ 2003-09-28 19:44         ` Jörn Engel
  0 siblings, 0 replies; 128+ messages in thread
From: Jörn Engel @ 2003-09-28 19:44 UTC (permalink / raw)
  To: Linus Torvalds, Geert Uytterhoeven, Bernardo Innocenti,
	Kernel Mailing List, Sam Ravnborg

On Sun, 28 September 2003 21:31:50 +0200, Sam Ravnborg wrote:
> On Sun, Sep 28, 2003 at 09:16:22PM +0200, Jörn Engel wrote:
> > How about a check_headers target that roughly works like this:
> > 
> > for (all header files in include/linux and include/asm) {
> > 	echo "#include <$HEADER>" > header.c
> > 	make header.o
> > 	rm header.c header.o
> > }
> 
> That should do it. Can you also integrate the check Linus mentioned,
> to make sure no declarations are present.

If it's simple enough, you'll have it tomorrow.  Linus' check might
take a bit longer, I'm not sure yet how to define an empty object
file.  Is it enough if objdump -tT only shows sections?

> I would name the target: headercheck:
> to be consistent with the other targets.

ok.

> It should be fine having it as a separate target, then we can ask
> John Cherry to include it in his nightly builds.

That would be nice, yes.

Jörn

-- 
Measure. Don't tune for speed until you've measured, and even then
don't unless one part of the code overwhelms the rest.
-- Rob Pike

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28 18:52     ` Linus Torvalds
@ 2003-09-28 19:44       ` Jamie Lokier
  0 siblings, 0 replies; 128+ messages in thread
From: Jamie Lokier @ 2003-09-28 19:44 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Sam Ravnborg, Geert Uytterhoeven, Bernardo Innocenti,
	Kernel Mailing List

Linus Torvalds wrote:
> On Sun, 28 Sep 2003, Sam Ravnborg wrote:
> > Would it help to require all major[1] header files to include all the
> > header files needed for them to compile?
> 
> It causes tons of extra work for the compiler if the compiler doesn't 
> optimize away redundant header files (same header file being included from 
> a lot of different sources).
>
> I did the pruning in sparse, and I think at least gcc-3 does it too, but 
> I'm not sure.

GCC does optimise away multiple header file inclusion, and has done
for a very long time, oh a decade or so :)

GCC will not reparse a header file if these conditions are met:

	1. The file has already been parsed at least once.

	2. Apart from comments, the entire file is surrounded by
	   "#ifndef symbol ... #endif" or "#if !defined (symbol) ... #endif".

	3. "symbol" is defined.

	4. The file names are the same after removal of "." and ".." components
	   and other path simplifications.

> If so, then sure, we could just require that the header files compile 
> cleanly, and for extra points verify that the end result is an empty 
> object file (ie no bad declarations anywhere..).

You can also use the "-H" option and check for a "Multiple include
guards may be useful for:" message, to check those #ifndefs.

-- Jamie

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28 19:16     ` Jörn Engel
  2003-09-28 19:31       ` Sam Ravnborg
@ 2003-09-28 19:42       ` Russell King
  2003-09-28 20:00         ` Jörn Engel
  2003-09-29 15:08         ` Chris Friesen
  1 sibling, 2 replies; 128+ messages in thread
From: Russell King @ 2003-09-28 19:42 UTC (permalink / raw)
  To: Jörn Engel
  Cc: Linus Torvalds, Geert Uytterhoeven, Bernardo Innocenti,
	Kernel Mailing List, Sam Ravnborg

On Sun, Sep 28, 2003 at 09:16:22PM +0200, Jörn Engel wrote:
> How about a check_headers target that roughly works like this:
> 
> for (all header files in include/linux and include/asm) {
> 	echo "#include <$HEADER>" > header.c
> 	make header.o
> 	rm header.c header.o
> }
> 
> Did a quick test for linux/fs.h in -test5 and it compiled fine, but
> broke after removing some random #include.
> 
> Another thing, Sam, "make header.o" causes make to call itself
> indefinitely.  Had to "make somedir/header.o".  Not sure if you
> consider this to be a bug, your decision.

I have a bad feeling about this, so I'll make the following comments
up front before all the reports start rolling in.  It may be a good
idea to document this somewhere.  (Coding style?)

If a header has something like these:

struct my_headers_struct {
	struct task_struct *tsk;
};

void my_function(struct task_struct *tsk);

and gcc warns that "struct task_struct" has not been declared, please
don't think about adding another header.  Just declare the structure
in the header file which needs it like this:

struct task_struct;

and that will prevent the #include maze of 2.4, which resulted in
everything being rebuilt just because one header file was touched.

-- 
Russell King (rmk@arm.linux.org.uk)	http://www.arm.linux.org.uk/personal/
      Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
      maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                      2.6 Serial core

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28 19:16     ` Jörn Engel
@ 2003-09-28 19:31       ` Sam Ravnborg
  2003-09-28 19:44         ` Jörn Engel
  2003-09-28 19:42       ` Russell King
  1 sibling, 1 reply; 128+ messages in thread
From: Sam Ravnborg @ 2003-09-28 19:31 UTC (permalink / raw)
  To: Jörn Engel
  Cc: Linus Torvalds, Geert Uytterhoeven, Bernardo Innocenti,
	Kernel Mailing List, Sam Ravnborg

On Sun, Sep 28, 2003 at 09:16:22PM +0200, Jörn Engel wrote:
> How about a check_headers target that roughly works like this:
> 
> for (all header files in include/linux and include/asm) {
> 	echo "#include <$HEADER>" > header.c
> 	make header.o
> 	rm header.c header.o
> }

That should do it. Can you also integrate the check Linus mentioned,
to make sure no declarations are present.

I would name the target: headercheck:
to be consistent with the other targets.

It should be fine having it as a separate target, then we can ask
John Cherry to include it in his nightly builds.

> Another thing, Sam, "make header.o" causes make to call itself
> indefinitely.  Had to "make somedir/header.o".  Not sure if you
> consider this to be a bug, your decision.

Thanks - I will try to look into it.

	Sam

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28 17:37 ` Linus Torvalds
  2003-09-28 18:46   ` Sam Ravnborg
@ 2003-09-28 19:28   ` Russell King
  2003-09-29  8:52     ` Geert Uytterhoeven
  2003-09-29 19:19   ` bill davidsen
  2 siblings, 1 reply; 128+ messages in thread
From: Russell King @ 2003-09-28 19:28 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Geert Uytterhoeven, Bernardo Innocenti, Kernel Mailing List

On Sun, Sep 28, 2003 at 10:37:36AM -0700, Linus Torvalds wrote:
> On Sun, 28 Sep 2003, Geert Uytterhoeven wrote:
> > On Sat, 27 Sep 2003, Linus Torvalds wrote:
> > > Bernardo Innocenti:
> > >   o GCC 3.3.x/3.4 compatiblity fix in include/linux/init.h
> > 
> > This change breaks 2.95 for some source files, because <linux/init.h> doesn't
> > include <linux/compiler.h>. Do you want to have the missing include added to
> > <linux/init.h>, or to the individual source files that need it?
> 
> Interesting. I'm pretty sure I did a "make allyesconfig" just before the
> test6 release, so apparently x86 includes it indirectly through some path, 
> and so it only shows up on m68k and arm?
> 
> This, btw, is a pretty common thing. I wonder what we could do to make 
> sure that different architectures wouldn't have so different include file 
> structures. It's happened _way_ too often.
> 
> Any ideas?

The two files that it showed up in on ARM are fairly simple in nature and
don't include may headers.  Making the ARM include structure identical to
x86 wouldn't have removed the problem from ARM.

-- 
Russell King (rmk@arm.linux.org.uk)	http://www.arm.linux.org.uk/personal/
      Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
      maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                      2.6 Serial core

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28 18:46   ` Sam Ravnborg
  2003-09-28 18:52     ` Linus Torvalds
@ 2003-09-28 19:16     ` Jörn Engel
  2003-09-28 19:31       ` Sam Ravnborg
  2003-09-28 19:42       ` Russell King
  1 sibling, 2 replies; 128+ messages in thread
From: Jörn Engel @ 2003-09-28 19:16 UTC (permalink / raw)
  To: Linus Torvalds, Geert Uytterhoeven, Bernardo Innocenti,
	Kernel Mailing List, Sam Ravnborg

On Sun, 28 September 2003 20:46:42 +0200, Sam Ravnborg wrote:
> On Sun, Sep 28, 2003 at 10:37:36AM -0700, Linus Torvalds wrote:
> > 
> > This, btw, is a pretty common thing. I wonder what we could do to make 
> > sure that different architectures wouldn't have so different include file 
> > structures. It's happened _way_ too often.
> > 
> > Any ideas?
> 
> Without too much thinking....
> Would it help to require all major[1] header files to include all the
> header files needed for them to compile?
> We could make that part of the build process or we could make that an
> optional step.
> 
> Obviously that would not solve any issues in asm-$(ARCH).
> 
> [1] There are ~600 files in include/linux - we could pick up the
> 50 most important and checkcompile them.

How about a check_headers target that roughly works like this:

for (all header files in include/linux and include/asm) {
	echo "#include <$HEADER>" > header.c
	make header.o
	rm header.c header.o
}

Did a quick test for linux/fs.h in -test5 and it compiled fine, but
broke after removing some random #include.

Another thing, Sam, "make header.o" causes make to call itself
indefinitely.  Had to "make somedir/header.o".  Not sure if you
consider this to be a bug, your decision.

Jörn

-- 
Fools ignore complexity.  Pragmatists suffer it.
Some can avoid it.  Geniuses remove it.
-- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept.  1982

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28 18:46   ` Sam Ravnborg
@ 2003-09-28 18:52     ` Linus Torvalds
  2003-09-28 19:44       ` Jamie Lokier
  2003-09-28 19:16     ` Jörn Engel
  1 sibling, 1 reply; 128+ messages in thread
From: Linus Torvalds @ 2003-09-28 18:52 UTC (permalink / raw)
  To: Sam Ravnborg; +Cc: Geert Uytterhoeven, Bernardo Innocenti, Kernel Mailing List


On Sun, 28 Sep 2003, Sam Ravnborg wrote:
>
> Would it help to require all major[1] header files to include all the
> header files needed for them to compile?

It causes tons of extra work for the compiler if the compiler doesn't 
optimize away redundant header files (same header file being included from 
a lot of different sources).

I did the pruning in sparse, and I think at least gcc-3 does it too, but 
I'm not sure.

If so, then sure, we could just require that the header files compile 
cleanly, and for extra points verify that the end result is an empty 
object file (ie no bad declarations anywhere..).

		Linus


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28 17:37 ` Linus Torvalds
@ 2003-09-28 18:46   ` Sam Ravnborg
  2003-09-28 18:52     ` Linus Torvalds
  2003-09-28 19:16     ` Jörn Engel
  2003-09-28 19:28   ` Russell King
  2003-09-29 19:19   ` bill davidsen
  2 siblings, 2 replies; 128+ messages in thread
From: Sam Ravnborg @ 2003-09-28 18:46 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Geert Uytterhoeven, Bernardo Innocenti, Kernel Mailing List

On Sun, Sep 28, 2003 at 10:37:36AM -0700, Linus Torvalds wrote:
> 
> This, btw, is a pretty common thing. I wonder what we could do to make 
> sure that different architectures wouldn't have so different include file 
> structures. It's happened _way_ too often.
> 
> Any ideas?

Without too much thinking....
Would it help to require all major[1] header files to include all the
header files needed for them to compile?
We could make that part of the build process or we could make that an
optional step.

Obviously that would not solve any issues in asm-$(ARCH).

[1] There are ~600 files in include/linux - we could pick up the
50 most important and checkcompile them.

	Sam

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28 10:14 Linux 2.6.0-test6 Geert Uytterhoeven
  2003-09-28 12:50 ` Russell King
@ 2003-09-28 17:37 ` Linus Torvalds
  2003-09-28 18:46   ` Sam Ravnborg
                     ` (2 more replies)
  1 sibling, 3 replies; 128+ messages in thread
From: Linus Torvalds @ 2003-09-28 17:37 UTC (permalink / raw)
  To: Geert Uytterhoeven; +Cc: Bernardo Innocenti, Kernel Mailing List


On Sun, 28 Sep 2003, Geert Uytterhoeven wrote:
> 
> On Sat, 27 Sep 2003, Linus Torvalds wrote:
> > Bernardo Innocenti:
> >   o GCC 3.3.x/3.4 compatiblity fix in include/linux/init.h
> 
> This change breaks 2.95 for some source files, because <linux/init.h> doesn't
> include <linux/compiler.h>. Do you want to have the missing include added to
> <linux/init.h>, or to the individual source files that need it?

Interesting. I'm pretty sure I did a "make allyesconfig" just before the
test6 release, so apparently x86 includes it indirectly through some path, 
and so it only shows up on m68k and arm?

This, btw, is a pretty common thing. I wonder what we could do to make 
sure that different architectures wouldn't have so different include file 
structures. It's happened _way_ too often.

Any ideas?

		Linus


^ permalink raw reply	[flat|nested] 128+ messages in thread

* RE: Linux 2.6.0-test6
  2003-09-28 12:19 Oliver Pitzeier
  2003-09-28 12:52 ` Geert Uytterhoeven
  2003-09-28 12:53 ` viro
@ 2003-09-28 13:54 ` Urban Widmark
  2 siblings, 0 replies; 128+ messages in thread
From: Urban Widmark @ 2003-09-28 13:54 UTC (permalink / raw)
  To: Oliver Pitzeier; +Cc: Linus Torvalds, Kernel Mailing List

On Sun, 28 Sep 2003, Oliver Pitzeier wrote:

> Hi folks/Linus!
> 
<snip>
> It work's on my Intel machine, but on Alpha, I get this:
> <snip>
<snip, snip>
> fs/built-in.o: In function `smb_fill_super':
> fs/built-in.o(.text+0xc9618): undefined reference to `low2highuid'
> fs/built-in.o(.text+0xc9624): undefined reference to `low2highuid'
> fs/built-in.o(.text+0xc963c): undefined reference to `low2highuid'
> fs/built-in.o(.text+0xc9640): undefined reference to `low2highuid'
> make: *** [.tmp_vmlinux1] Error 1

This patch should solve this.

Linus, please apply unless you dislike OLD_TO_NEW_GID.
smbfs is the only user of it and could check CONFIG_UID16 itself.

/Urban

--- linux-2.6.0-test5-smbfs/fs/smbfs/inode.c-orig	Fri Sep 26 21:06:55 2003
+++ linux-2.6.0-test5-smbfs/fs/smbfs/inode.c	Fri Sep 26 20:58:00 2003
@@ -551,8 +551,8 @@
 	if (ver == SMB_MOUNT_OLDVERSION) {
 		mnt->version = oldmnt->version;
 
-		mnt->uid = low2highuid(oldmnt->uid);
-		mnt->gid = low2highuid(oldmnt->gid);
+		mnt->uid = OLD_TO_NEW_UID(oldmnt->uid);
+		mnt->gid = OLD_TO_NEW_GID(oldmnt->gid);
 
 		mnt->file_mode = (oldmnt->file_mode & S_IRWXUGO) | S_IFREG;
 		mnt->dir_mode = (oldmnt->dir_mode & S_IRWXUGO) | S_IFDIR;
--- linux-2.6.0-test5-smbfs/include/linux/highuid.h-orig	Fri Sep 26 21:07:34 2003
+++ linux-2.6.0-test5-smbfs/include/linux/highuid.h	Fri Sep 26 21:07:42 2003
@@ -56,6 +56,8 @@
 #define SET_GID16(var, gid)	var = high2lowgid(gid)
 #define NEW_TO_OLD_UID(uid)	high2lowuid(uid)
 #define NEW_TO_OLD_GID(gid)	high2lowgid(gid)
+#define OLD_TO_NEW_UID(uid)	low2highuid(uid)
+#define OLD_TO_NEW_GID(gid)	low2highgid(gid)
 
 /* specific to fs/stat.c */
 #define SET_OLDSTAT_UID(stat, uid)	(stat).st_uid = high2lowuid(uid)
@@ -69,6 +71,8 @@
 #define SET_GID16(var, gid)	do { ; } while (0)
 #define NEW_TO_OLD_UID(uid)	(uid)
 #define NEW_TO_OLD_GID(gid)	(gid)
+#define OLD_TO_NEW_UID(uid)	(uid)
+#define OLD_TO_NEW_GID(gid)	(gid)
 
 #define SET_OLDSTAT_UID(stat, uid)	(stat).st_uid = (uid)
 #define SET_OLDSTAT_GID(stat, gid)	(stat).st_gid = (gid)


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28 12:50 ` Russell King
@ 2003-09-28 13:54   ` Bernardo Innocenti
  0 siblings, 0 replies; 128+ messages in thread
From: Bernardo Innocenti @ 2003-09-28 13:54 UTC (permalink / raw)
  To: Russell King; +Cc: Geert Uytterhoeven, Linus Torvalds, Kernel Mailing List

Russell King wrote:

>>>Bernardo Innocenti:
>>>  o GCC 3.3.x/3.4 compatiblity fix in include/linux/init.h
>>
>>This change breaks 2.95 for some source files, because <linux/init.h> doesn't
>>include <linux/compiler.h>. Do you want to have the missing include added to
>><linux/init.h>, or to the individual source files that need it?

The golden rule of C headers says that each file should stand
on its own, so that you have no errors when compiling the header
alone.

This is the trivial fix. Sorry for not noticing before.

--- include/linux/init.h.orig	2003-09-28 15:48:06.000000000 +0200
+++ include/linux/init.h	2003-09-28 15:48:10.000000000 +0200
@@ -2,6 +2,7 @@
 #define _LINUX_INIT_H
 
 #include <linux/config.h>
+#include <linux/compiler.h>
 
 /* These macros are used to mark some functions or 
  * initialized data (doesn't apply to uninitialized data)


-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html




^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28 12:19 Oliver Pitzeier
  2003-09-28 12:52 ` Geert Uytterhoeven
@ 2003-09-28 12:53 ` viro
  2003-09-28 13:54 ` Urban Widmark
  2 siblings, 0 replies; 128+ messages in thread
From: viro @ 2003-09-28 12:53 UTC (permalink / raw)
  To: Oliver Pitzeier; +Cc: Linus Torvalds, Kernel Mailing List

On Sun, Sep 28, 2003 at 02:19:24PM +0200, Oliver Pitzeier wrote:
> Hi folks/Linus!
> 
> Linus Torvalds wrote:
> > Ok, too long between test5 and test6 again, so the patch is 
> > pretty big. Lots of driver updates and architectures fixed, 
> > but also lots of merges from Andrew Morton. Most notably 
> > perhaps Con's scheduler changes that have been discussed 
> > extensively and made it into the -mm tree for testing.
> 
> It work's on my Intel machine, but on Alpha, I get this:
> <snip>
>   CC      init/version.o
>   LD      init/built-in.o
>   LD      .tmp_vmlinux1
> kernel/built-in.o: In function `try_to_wake_up':
> kernel/built-in.o(.text+0x438): undefined reference to `sched_clock'

Add
unsigned long long default_sched_clock(void)
{
	return (unsigned long long)jiffies * (1000000000 / HZ);
}

in kernel/sched.c and

#define sched_clock default_sched_clock

in include/asm-alpha/system.h

FWIW, the former should've been done from the very beginning and sched_clock
should've been made a weak alias for default_sched_clock.  That would avoid
the breakage of platforms original patch didn't update.

BTW, how about adding weak_alias(type, name, args, default_variant) to
compiler.h?  For most platforms it would be

#define weak_alias(type, name, args, default_variant) \
	type name args __attribute__((weak, alias(#default_variant)));

Note that we already have something similar - cond_syscall(name) would
become weak_alias(asmlinkage long, name, (void), sys_ni_syscall) and
platform-specific stuff could be taken from current definitions of this
beast.

^ permalink raw reply	[flat|nested] 128+ messages in thread

* RE: Linux 2.6.0-test6
  2003-09-28 12:19 Oliver Pitzeier
@ 2003-09-28 12:52 ` Geert Uytterhoeven
  2003-09-28 21:41   ` Andrew Morton
  2003-09-28 12:53 ` viro
  2003-09-28 13:54 ` Urban Widmark
  2 siblings, 1 reply; 128+ messages in thread
From: Geert Uytterhoeven @ 2003-09-28 12:52 UTC (permalink / raw)
  To: Oliver Pitzeier; +Cc: Linus Torvalds, Kernel Mailing List

On Sun, 28 Sep 2003, Oliver Pitzeier wrote:
> Linus Torvalds wrote:
> > Ok, too long between test5 and test6 again, so the patch is 
> > pretty big. Lots of driver updates and architectures fixed, 
> > but also lots of merges from Andrew Morton. Most notably 
> > perhaps Con's scheduler changes that have been discussed 
> > extensively and made it into the -mm tree for testing.
> 
> It work's on my Intel machine, but on Alpha, I get this:
> <snip>
>   CC      init/version.o
>   LD      init/built-in.o
>   LD      .tmp_vmlinux1
> kernel/built-in.o: In function `try_to_wake_up':
> kernel/built-in.o(.text+0x438): undefined reference to `sched_clock'
> kernel/built-in.o(.text+0x43c): undefined reference to `sched_clock'
> kernel/built-in.o: In function `schedule':
> kernel/built-in.o(.text+0x13e4): undefined reference to `sched_clock'
> kernel/built-in.o(.text+0x13ec): undefined reference to `sched_clock'
> kernel/built-in.o: In function `copy_process':
> kernel/built-in.o(.text+0x5014): undefined reference to `sched_clock'
> kernel/built-in.o(.text+0x503c): more undefined references to `sched_clock' follow

There's a new architecture-specific routine sched_clock() to be implemented
(which was BTW not announced on the secret all-architectures mail alias ;-).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
  2003-09-28 10:14 Linux 2.6.0-test6 Geert Uytterhoeven
@ 2003-09-28 12:50 ` Russell King
  2003-09-28 13:54   ` Bernardo Innocenti
  2003-09-28 17:37 ` Linus Torvalds
  1 sibling, 1 reply; 128+ messages in thread
From: Russell King @ 2003-09-28 12:50 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Bernardo Innocenti, Linus Torvalds, Kernel Mailing List

On Sun, Sep 28, 2003 at 12:14:18PM +0200, Geert Uytterhoeven wrote:
> 
> On Sat, 27 Sep 2003, Linus Torvalds wrote:
> > Bernardo Innocenti:
> >   o GCC 3.3.x/3.4 compatiblity fix in include/linux/init.h
> 
> This change breaks 2.95 for some source files, because <linux/init.h> doesn't
> include <linux/compiler.h>. Do you want to have the missing include added to
> <linux/init.h>, or to the individual source files that need it?

It also breaks gcc 3.2.2 / gcc 3.3 as well:

arch/arm/mach-sa1100/leds.c:51: error: parse error before "__attribute_used__"
arch/arm/mach-pxa/leds.c:29: error: parse error before "__attribute_used__"

-- 
Russell King (rmk@arm.linux.org.uk)	http://www.arm.linux.org.uk/personal/
      Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
      maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                      2.6 Serial core

^ permalink raw reply	[flat|nested] 128+ messages in thread

* RE: Linux 2.6.0-test6
@ 2003-09-28 12:19 Oliver Pitzeier
  2003-09-28 12:52 ` Geert Uytterhoeven
                   ` (2 more replies)
  0 siblings, 3 replies; 128+ messages in thread
From: Oliver Pitzeier @ 2003-09-28 12:19 UTC (permalink / raw)
  To: Linus Torvalds, Kernel Mailing List

Hi folks/Linus!

Linus Torvalds wrote:
> Ok, too long between test5 and test6 again, so the patch is 
> pretty big. Lots of driver updates and architectures fixed, 
> but also lots of merges from Andrew Morton. Most notably 
> perhaps Con's scheduler changes that have been discussed 
> extensively and made it into the -mm tree for testing.

It work's on my Intel machine, but on Alpha, I get this:
<snip>
  CC      init/version.o
  LD      init/built-in.o
  LD      .tmp_vmlinux1
kernel/built-in.o: In function `try_to_wake_up':
kernel/built-in.o(.text+0x438): undefined reference to `sched_clock'
kernel/built-in.o(.text+0x43c): undefined reference to `sched_clock'
kernel/built-in.o: In function `schedule':
kernel/built-in.o(.text+0x13e4): undefined reference to `sched_clock'
kernel/built-in.o(.text+0x13ec): undefined reference to `sched_clock'
kernel/built-in.o: In function `copy_process':
kernel/built-in.o(.text+0x5014): undefined reference to `sched_clock'
kernel/built-in.o(.text+0x503c): more undefined references to `sched_clock' follow
fs/built-in.o: In function `smb_fill_super':
fs/built-in.o(.text+0xc9618): undefined reference to `low2highuid'
fs/built-in.o(.text+0xc9624): undefined reference to `low2highuid'
fs/built-in.o(.text+0xc963c): undefined reference to `low2highuid'
fs/built-in.o(.text+0xc9640): undefined reference to `low2highuid'
make: *** [.tmp_vmlinux1] Error 1

If you need more information please ask me (CC: me please).

Best,
 Oliver


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.0-test6
@ 2003-09-28 10:14 Geert Uytterhoeven
  2003-09-28 12:50 ` Russell King
  2003-09-28 17:37 ` Linus Torvalds
  0 siblings, 2 replies; 128+ messages in thread
From: Geert Uytterhoeven @ 2003-09-28 10:14 UTC (permalink / raw)
  To: Bernardo Innocenti; +Cc: Linus Torvalds, Kernel Mailing List


On Sat, 27 Sep 2003, Linus Torvalds wrote:
> Bernardo Innocenti:
>   o GCC 3.3.x/3.4 compatiblity fix in include/linux/init.h

This change breaks 2.95 for some source files, because <linux/init.h> doesn't
include <linux/compiler.h>. Do you want to have the missing include added to
<linux/init.h>, or to the individual source files that need it?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


^ permalink raw reply	[flat|nested] 128+ messages in thread

end of thread, other threads:[~2003-10-12 11:42 UTC | newest]

Thread overview: 128+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-09-28  1:27 Linux 2.6.0-test6 Linus Torvalds
2003-09-28  7:03 ` Con Kolivas
2003-09-28 10:02   ` Rob Landley
2003-09-29  4:55     ` Nick Piggin
2003-09-29  7:35       ` Rob Landley
2003-09-29 16:55       ` Ed Sweetman
2003-09-30  0:03         ` Nick Piggin
2003-10-02  0:41         ` Pedro Larroy
2003-10-02  3:05           ` Nick Piggin
2003-10-02 19:07             ` Pedro Larroy
2003-10-03  0:07               ` Nick Piggin
2003-10-03 19:34                 ` Pedro Larroy
2003-09-29 18:45       ` bill davidsen
2003-09-30  1:12         ` Nick Piggin
2003-10-01 21:13           ` bill davidsen
2003-10-02  2:45             ` Nick Piggin
2003-09-28  8:26 ` Markus Hästbacka
2003-09-28 10:54   ` Jeff Garzik
2003-09-28  8:59 ` keyboard repeat / sound [was Re: Linux 2.6.0-test6] Roger Luethi
2003-09-29 15:16   ` Vojtech Pavlik
2003-09-30  7:50     ` Paul
2003-09-30 12:51       ` Vojtech Pavlik
2003-09-30 13:21         ` Aristeu Sergio Rozanski Filho
2003-09-30 13:44           ` Vojtech Pavlik
2003-09-30 14:05             ` Aristeu Sergio Rozanski Filho
2003-09-30 14:16               ` Vojtech Pavlik
2003-10-01 23:51                 ` Aristeu Sergio Rozanski Filho
2003-09-30 18:16               ` Mark W. Alexander
2003-10-01 23:52                 ` Aristeu Sergio Rozanski Filho
2003-09-28 10:09 ` Linux 2.6.0-test6 Rafał 'rmrmg' Roszak
2003-09-28 11:05 ` Andreas Jellinghaus
2003-09-28 12:34   ` Dave Jones
2003-09-28 16:12     ` Andreas Jellinghaus
2003-09-28 17:51       ` Andries Brouwer
2003-09-28 16:42 ` Ivan Gyurdiev
2003-09-28 20:26 ` [patch] 2.6.0-test6: correct hdlcdrv.h prototypes Adrian Bunk
2003-09-29 13:23 ` Linux 2.6.0-test6 Florin Iucha
2003-09-29 13:55   ` Muli Ben-Yehuda
2003-09-29 14:01     ` Jaroslav Kysela
2003-09-29 14:18       ` Muli Ben-Yehuda
2003-09-29 19:04         ` bill davidsen
2003-09-29 14:30       ` Takashi Iwai
2003-09-29 13:58   ` Jaroslav Kysela
2003-09-29 16:30 ` Linux 2.6.0-test6 (compile statistics) John Cherry
2003-09-29 17:44   ` Jesper Juhl
2003-10-06 20:39     ` John Cherry
2003-10-01  8:58 ` Who changed /proc/<pid>/ in 2.6.0-test5-bk9? Mikael Pettersson
2003-10-01 11:52   ` John Levon
2003-10-01 20:21     ` bill davidsen
2003-10-02  1:00       ` John Levon
2003-10-06  3:01         ` bill davidsen
2003-10-01 15:11   ` Linus Torvalds
2003-10-01 20:58     ` bill davidsen
2003-10-01 23:42     ` Albert Cahalan
2003-10-02  0:38       ` Linus Torvalds
2003-10-02  0:57         ` Albert Cahalan
2003-10-02  3:35     ` Ulrich Drepper
2003-10-02  4:12       ` Albert Cahalan
2003-10-02  4:58         ` Ulrich Drepper
2003-10-02 13:48           ` Albert Cahalan
2003-10-02 17:30             ` Ulrich Drepper
2003-10-03  0:03               ` Albert Cahalan
2003-10-03  0:40                 ` Linus Torvalds
2003-10-03  2:53                   ` Jamie Lokier
2003-10-06  4:54                     ` Mike Fedyk
2003-10-06  2:52                   ` bill davidsen
2003-10-07 23:08                   ` Robert White
2003-10-07 22:46                 ` Robert White
2003-10-07 23:25                   ` Linus Torvalds
2003-10-08  0:41                     ` Robert White
2003-10-08  0:54                       ` Linus Torvalds
2003-10-08  2:31                         ` Robert White
2003-10-08  2:39                           ` David Lang
2003-10-08  2:59                             ` Robert White
2003-10-09 18:25                               ` bill davidsen
2003-10-08  2:47                           ` Who changed /proc/<pid>/ in 2.6.0-test5-bk9? (SIGPIPE?) Robert White
2003-10-08  2:57                             ` Linus Torvalds
2003-10-08  4:01                               ` Robert White
2003-10-08  4:08                                 ` Linus Torvalds
2003-10-08 10:47                         ` Who changed /proc/<pid>/ in 2.6.0-test5-bk9? bert hubert
2003-10-08 19:12                           ` Ulrich Drepper
2003-10-09 18:43                             ` bill davidsen
2003-10-08 21:54                           ` Robert White
2003-10-09 18:12                         ` bill davidsen
2003-10-10  4:39                           ` Jamie Lokier
2003-10-09 17:59                       ` bill davidsen
2003-10-11  3:02                       ` Here is a case that proves my previous position wrong regurading CLONE_THREAD and CLONE_FILES Robert White
2003-10-11  3:48                         ` viro
2003-10-12 11:41                         ` Jamie Lokier
2003-10-02  8:46       ` Who changed /proc/<pid>/ in 2.6.0-test5-bk9? Miquel van Smoorenburg
2003-10-02 22:35         ` Jamie Lokier
2003-10-02 23:43           ` Miquel van Smoorenburg
2003-10-06  2:57         ` bill davidsen
2003-10-02  3:38     ` Ulrich Drepper
2003-09-28 10:14 Linux 2.6.0-test6 Geert Uytterhoeven
2003-09-28 12:50 ` Russell King
2003-09-28 13:54   ` Bernardo Innocenti
2003-09-28 17:37 ` Linus Torvalds
2003-09-28 18:46   ` Sam Ravnborg
2003-09-28 18:52     ` Linus Torvalds
2003-09-28 19:44       ` Jamie Lokier
2003-09-28 19:16     ` Jörn Engel
2003-09-28 19:31       ` Sam Ravnborg
2003-09-28 19:44         ` Jörn Engel
2003-09-28 19:42       ` Russell King
2003-09-28 20:00         ` Jörn Engel
2003-09-28 21:43           ` Tim Schmielau
2003-09-28 21:54             ` Arnaldo Carvalho de Melo
2003-09-29 15:08         ` Chris Friesen
2003-09-29 15:14           ` Geert Uytterhoeven
2003-09-28 19:28   ` Russell King
2003-09-29  8:52     ` Geert Uytterhoeven
2003-09-29 19:19   ` bill davidsen
2003-09-30 10:42     ` Jörn Engel
2003-09-30 15:17       ` Bill Davidsen
2003-10-01  9:08         ` Jörn Engel
2003-09-28 12:19 Oliver Pitzeier
2003-09-28 12:52 ` Geert Uytterhoeven
2003-09-28 21:41   ` Andrew Morton
2003-09-29  9:58     ` Geert Uytterhoeven
2003-09-29 10:08       ` Russell King
2003-09-29 19:19         ` Anton Blanchard
2003-09-28 12:53 ` viro
2003-09-28 13:54 ` Urban Widmark
2003-09-29  9:00 Oliver Pitzeier
     [not found] <&lt;3F7CBDD4.7010503@cyberone.com.au&gt;>
2003-10-03  3:51 ` Jason Munro
2003-10-06  3:05   ` bill davidsen
2003-10-09 18:44   ` bill davidsen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).