linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Linux 2.5.70
@ 2003-05-27  2:08 Linus Torvalds
  2003-05-27  2:45 ` Linux 2.5.70 (Compiler warnings) Udo A. Steinberg
                   ` (5 more replies)
  0 siblings, 6 replies; 55+ messages in thread
From: Linus Torvalds @ 2003-05-27  2:08 UTC (permalink / raw)
  To: Kernel Mailing List


Ok, 
 there's been too much delay between 69 and 70, but I was hoping to make 
70 the last "Linus only" release before getting together with Andrew and 
figuring out how to start the "pre-2.6" series and more of a code slush. 

Whatever. Th eend result is a pretty big patch, although a lot of it is
due to fairly minor patches. But it's a _lot_ of fairly minor patches, as
can be seen from the changelog (also, the acorn drivers got moved around,
which always makes for big patches).

		Linus


Summary of changes from v2.5.69 to v2.5.70
============================================

<lkml001:vrfy.org>:
  o USB: usb-skeleton compile fix

<olof:austin.ibm.com>:
  o [TCP]: tcp_twkill leaves death row list in inconsistent state over
    tcp_timewait_kill

<philipp:void.at>:
  o USB: unusual_devs.h patch

<willschm:us.ibm.com>:
  o add #ifdef CONFIG_XMON around a XMON variable reference
  o ppc64: add spinlock to chrp_progress
  o ppc64: restore hex progress code

Adrian Bunk:
  o USB: kill the last occurances of usb_serial_get_by_minor
  o [NET]: wireless.c needs module.h

Alan Stern:
  o USB: uhci Interrupt Latency fix
  o USB: Addition to previous patch needed for PM UHCI

Alex Williamson:
  o ia64: fix GENERIC build
  o ia64: small ACPI fix
  o ia64: fix timer interrupts getting lost
  o ia64: interrupt fixes/cleanup

Alexander Viro:
  o seq_path(), /proc/mounts and /proc/swaps
  o seq_path() for /proc/pid/maps
  o O_DIRECT open() fix
  o TIOCCONS fix
  o cpqarray fixes
  o pg.c macroectomy
  o pg.c Lindent
  o pg.c macroectomy - part 2
  o pt.c macroectomy
  o pt.c Lindent
  o switch blk_register_area() to kobject
  o register_chrdev_region() cleanup
  o kobj_map
  o cdev-cidr, part 1
  o i_cdev/i_cindex

Alexey Kuznetsov:
  o [ACENIC]: Comment out netif_wake_queue from acenic watchdog

Andi Kleen:
  o [NET]: Clean up socket filter compat handling
  o x86-64 merge
  o Make ACPI compile again on 64bit/gcc 3.3

Andrew Morton:
  o [NET]: Remove duplicated alloc_skb debug check
  o generic subarchitecture for ia32
  o Fix .altinstructions linking failures
  o cpia driver __exit fix
  o fix OSS opl3sa2 compilation
  o misc fixes
  o mwave build fix
  o drm timer initialisation fix
  o slab: initialisation cleanup and oops fix
  o sysrq-S, sysrq-U cleanups
  o s/UPDATE_ATIME/update_atime/ cleanup
  o irqreturn_t for drivers/net/pcmcia
  o keyboard.c Fix CONFIG_MAGIC_SYSRQ+PrintScreen
  o Don't use devfs names in disk_name()
  o devfs: API changes
  o remove partition_name()
  o switch most remaining drivers over to devfs_mk_bdev
  o dvbdev fixes
  o access_ok() race fix for 80386
  o hold i_sem on swapfiles
  o remove unnecessary PAE pgd set
  o account for slab reclaim in try_to_free_pages()
  o slab: additional debug checks
  o reduced overheads in fget/fput
  o allow i8042 interrupt sharing
  o select() speedup
  o Move security_d_instantiate hook calls
  o ext3 xattr handler for security modules
  o ext2 xattr handler for security modules
  o Change LSM hooks in setxattr
  o Work around include/linux/sunrpc/svc.h compilation
  o [netdrvr] remaining irqreturn_t changes
  o enable slab debugging for larger objects
  o Remove __verify_write leftovers
  o hrtimers: fix timer_create(2) && SIGEV_NONE
  o implement module_arch_cleanup() in all architectures
  o remove devfs_register
  o fix pnp_test_handler return
  o fat cluster search speedup
  o Fix for vma merging refcounting bug
  o Commented out printk causes change in program flow in
  o small cleanup for __rmqueue
  o export cpufreq_driver to fix oops in proc interface
  o Quota write transaction size fix
  o dquot_transfer() fix
  o Bump module ref during init
  o exit_mmap() TASK_SIZE fix
  o semop race fix
  o visws: fix penguin with sgi logo
  o fix for clusterd io_apics
  o provide user feedback for emergency sync and remount
  o copy_process return value fix
  o de_thread memory corruption fix
  o vmalloc race fix
  o Reserve the ext2/ext3 EAs for the Lustre filesystem
  o Fix arch/i386/oprofile/init.c build error
  o Fix ext3 htree / NFS compatibility problems
  o htree nfs fix
  o ext3: htree memory leak fix
  o [NET]: netif_receive_skb() warning fix
  o [ATM]: Fix macro pasting in HE driver
  o USB: net2280 writel fix
  o [NET]: Fix sb1000.c build
  o ipmi warning fixes
  o sound/core comparison fix
  o pass the stack protection flags into put_dirty_page()
  o fix hugetlbpage scoping
  o DAC960 typedef cleanup patch
  o loop.c warning removal
  o mtrr warning fix
  o SMI clearing fix
  o Make debugging variant of spinlocks a bit more robust
  o fix lots of error-path memory leaks
  o miropcm20-rds.c build fix
  o synclink_cs update
  o remove some cruft from smp.h
  o >llseek returns loff_t, even for /dev/mem
  o visws: fix for generic-subarch
  o fix bug in drivers/net/cs89x0.c:set_mac_address()
  o Allow architecture to overwrite stack flags
  o [CRYPTO]: Fix memcpy/memset args
  o sysfs_create_link() fix
  o ia32 subarch circular dependency fix
  o genarch cpu_mask_to_apicid fix
  o [patch 4/29 voyager cpu_callout_map fix
  o ppp warning fix
  o misc fixes
  o large-dma_addr_t-PAE-only.patch
  o 3c59x irqreturn fix
  o reiserfs: allow multiple block insertion into the tree
  o reiserfs: reiserfs_file_write implementation
  o fix CONFIG_APM=m
  o Fix for latent bug in vmtruncate()
  o v4l: #1 - video-buf update
  o v4l: #2 - v4l1-compat update
  o v4l: #4 - bttv docmentation update
  o v4l: #5 - i2c module updates
  o v4l: #6 - tuner module update
  o v4l: #7 - saa7134 driver update
  o fix tuner.c and tda9887.c
  o radeonfb.c 64-bit fixes
  o use %p to print pointers in cs4281
  o memcpy/memset fixes
  o BUG() -> BUG_ON() conversions
  o 3c59x: add support for 3c905B-T4, 3C920B-EMB-WNM
  o CONFIG_ACPI_SLEEP compile fix
  o fix handling of spares physical APIC ids
  o put_page_testzero() fix
  o DAC960 oops fix
  o apply_alternatives() fix
  o sound/core/memalloc.c needs mm.h
  o revert sysfs non-fix
  o ppc64 update for do_fork() change
  o shrink_all_memory() fix
  o ppc64: 32/64bit emulation for aio
  o ppc64: Fix some PPC64 compile warnings
  o ppc64: PPC64 irq return fix
  o ppc64: Squash warning in ppc64 addnote tool
  o ppc64: Squash implicit declaration warning in ppc64
  o ppc64: do_signal32 warning fix
  o ppc64: Squash warning in ppc64 xics.c
  o ppc64: Unused variables in ppc64 prom.c
  o ppc64: build fix
  o ppc64: ioctl32 warning fix
  o ppc64: nail warnings in arch/ppc64/kernel/setup.c
  o ppc64: arch/ppc64/kernel/traps.c warning fixes
  o ppc64: more warning fixes
  o tty_io warning fix
  o siocdevprivate_ioctl warning fix
  o arch/i386/kernel/mpparse.c warning fixes
  o Fix dcache_lock/tasklist_lock ranking bug
  o APM does unsafe conditional set_cpus_allowed
  o reiserfs: inode attributes support
  o xirc2ps_cs irq return fix
  o Fix readdir error return value
  o Don't remove inode from hash until filesystem has
  o slab: account for reclaimable caches
  o mark shrinkable slabs as being reclaimable
  o Process Attribute API for Security Modules
  o Process Attribute API for Security Modules (fixlet)
  o /proc/pid inode security labels
  o CONFIG_FUTEX
  o CONFIG_EPOLL
  o devpts xattr handler for security labels
  o overcommit root margin
  o net/sunrpc/sunrpc_syms.c typo fix
  o add notify_count for de_thread
  o extend-check_valid_hugepage_range.patch
  o misc fixes
  o Documentation for disk iostats
  o Remove floating point use in cpia.c
  o rd.c: separate queue per disk
  o Better fix for ia32 subarch circular dependencies
  o fix drivers/net/ewrk.c memory leak
  o fix init/do_mounts_rd.c memory leak
  o two PNP memory leaks
  o Change mmu_gathers into per-cpu data
  o arch/i386/kernel/srat.c cast warning fix
  o ACPI constant overflow fixes
  o tulip warning fix
  o use update_mmu_cache() in install_page

Andries E. Brouwer:
  o namespace fix
  o NCR5380.c fix
  o fix oops in namespace.c
  o [NET]: Use ARRAY_SIZE where appropriate
  o namespace.c fix
  o change get_sb prototype
  o kill lvm from parisc
  o kill lvm from x86_64
  o some typos
  o kill ide-geometry
  o kill lvm from compat_ioctl.h

Andy Grover:
  o ACPI: Update to 20030424
  o ACPI: kobject fix (Greg KH) Here's a small patch that fixes the
    logic of the kobject creation and registration in the acpi code
    (since we use kobject_init(), we need to use kobject_add(), not
    kobject_register() to add the kobject to the kernel systems).
  o ACPI: Allow ":" in OS override string (Ducrot Bruno)
  o ACPI: Interpreter update to 20030509 Changed the subsystem
    initialization sequence to hold off installation of address space
    handlers until the hardware has been initialized and the system has
    entered ACPI mode.  This is because the installation of space
    handlers can cause _REG methods to be run.  Previously, the _REG
    methods could potentially be run before ACPI mode was enabled.
  o ACPI: Return only proper values (0 or 1) from our interrupt handler
    (Andrew Morton)
  o ACPI: Update Toshiba driver to 0.15 (John Belmonte)
  o ACPI: Do not reinit ACPI irq entry in ioapic (thanks to Stian
    Jordet)
  o ACPI: update to 20030522
  o ACPI: Allow multiple compatible IDs for PnP purposes

Anton Blanchard:
  o ppc64: add autofs ioctl and clean up a prototype
  o ppc64: xics cleanup
  o ppc64: clean up some cpu feature checks
  o ppc64: fix NR_syscalls slip up
  o ppc64: fix for recent module changes
  o ppc64: return ENOSYS for unknown IPC call
  o ppc64: Fix for outside of range sensor states, from John Rose
  o ppc64: segment misses from userspace must pass through
    do_page_fault
  o ppc64: use panic_on_oops sysctl
  o ppc64: use dma-window from deepest device tree node, from Dave
    Engebretsen
  o ppc64: chrp_progress() updates from Olof Johansson
  o ppc64: ethtool -e support, from Olof Johansson
  o ppc64: update ppc64 to new IRQ API from Andrew Morton
  o ppc64: fix some compile warnings, from Andrew Morton
  o ppc64: Fix some things that got backed out in the systemcfg merge
  o ppc64: Add loop_get_status64/loop_set_status64
  o ppc64: Andrew Morton is picking on me
  o ppc64: remove numa_node_exists, from Martin Bligh
  o ppc64: clear up the cpu<-> node mappings, and cache them, from Matt
    Dobson
  o ppc64: remove iomem_resource.end hack
  o Re: Make sym2 driver use pci_enable_device
  o ppc64: ioctl32 updates
  o ppc64: rework fast SLB miss handler castout code
  o ppc64: firmware flash fix from Olof Johansson
  o USB: gadget compile error on ppc64

Arnaldo Carvalho de Melo:
  o ipx headers: Coding Style code reformatting
  o list.h: implement list_for_each_entry_safe
  o ipx: convert ipx_interface handling to use list_head
  o ipx: convert ipx_route to use list_head
  o ipx: ipx_interfaces outlives struct sock/socket
  o wanrouter: add missing include module.h
  o [IPV4/IPV6]: Consolidate saddr resetting into inet_reset_saddr()
  o ipv4/ipv6: use ipv6_addr_copy where appropriate
  o ipv4/ipv6: call tcp_timewait_kill in tcp_tw_deschedule
  o af_netlink: netlink_proto_init has to be core_initcall
  o wanrouter: don't use typedefs for wan_device, just struct
    wan_device
  o wanrouter: kill netdevice_t, do as all the rest of the tree, use
    struct net_device
  o wan/cycx: typedef cleanup
  o wan/cycx: fix module refcounting, removing
    MOD_{INC,DEC}_USE_COUNT
  o wan/cycx: further cleanups
  o wan/cycx: remove more typedefs
  o wan/cycx: remove the last typedefs, some kernel doc comments
  o wan/cycx: use min_t and remove one more private MIN()
    implementation
  o ipx: remove debug message for successfull bind
  o ipx: move route functions to net/ipx/ipx_route.c
  o ipv6/route: fix .dst.metrics struct init for ip6_null_entry
  o ipv6/route: use C99 style init for struct init
  o ipv6/addrconf: use C99 struct init style for
    inet6_rtnetlink_table
  o ipv6/exthdrs: use C99 struct init style
  o ipv6/icmp: use C99 struct style init for tab_unreach
  o ipv6/ip6_fib: use C99 struct style init and move rt_sernum to
    .bss
  o wanrouter/wanproc: code cleanups
  o drivers/net/wan/sdla*: use SET_MODULE_OWNER at net_device setup
  o sock.h: kernel-doc style comment for struct sock
  o wan/cycx: remove unneeded ioctl stub and fix namespace
  o wanrouter/wanmain: fix namespace, fixing the current problem with
    device_shutdown
  o icmp: cleanups, use C99 array init style, etc

Arun Sharma:
  o ia64: make x86 shared programs work again
  o ia64: fix ia32 emulation of rlimit et al
  o ia64: fix sys32_select()

Bart De Schuymer:
  o [BRIDGE]: Change pkt_type to PACKET_HOST earlier
  o [BRIDGE]: Deal with non-linear SKBs in ebtables

Bartlomiej Zolnierkiewicz:
  o fix lost IDE interrupt problem
  o Fix incorrect enablebits for all AMD and nVidia IDE chipsets
  o Add IDE support for VIA vt8237 southbridge
  o Intel ICH5 basic SATA support
  o misc AMD IDE driver fixes
  o add hwif->hold flag
  o SiS IDE driver fixes
  o ServerWorks IDE driver update
  o add hwif->rw_disk callout
  o _IDE_C cleanup
  o IDE: fix "biostimings" and legacy chipsets' boot parameters
    interaction
  o Probe legacy IDE chipsets in ide_init() instead of in ide_setup()

Ben Collins:
  o USB: Happ UGCI added as BADPAD for workaround
  o Update IEEE1394 (r931)
  o A few more strlcpy's for drivers/base/
  o sound/* strncpy conversion
  o fs/* conversions for strlcpy
  o do_mounts.c strlcpy
  o Fix snd_seq_queue_find_name()
  o kernel/* strlcpy conversion
  o [NET]: strncpy -> strlcpy conversions
  o arch/* strlcpy conversion
  o drivers/* strlcpy conversions

Benjamin Herrenschmidt:
  o [SUNGEM]: Updates from PowerPC people
  o drivers/ide/ppc/pmac.c compile fix

Bjorn Helgaas:
  o ia64: sba_iommu workaround removal
  o ia64: sba_iommu vendor/function for unknown IOCs
  o ia64: sba_iommu trivial cleanup
  o ia64: multi-ioport space support
  o ia64: multi-ioport space support (part 2 of 4)
  o ia64: multi-ioport space support (part 3 of 4)
  o ia64: multi-ioport space support (part 3 of 4)
  o ia64: new IOC recognition
  o ia64: vendor-specific ACPI resource cleanup

Brian Gerst:
  o Fix ioperm bitmap
  o remove fake_sep_struct

Charles Fumuso:
  o [XFS] Merge over an irix fix

Chas Williams:
  o [ATM]: Fix excessive stack usage in iphase driver
  o [ATM]: svcs possible race with sigd
  o [ATM]: Fix foul up in lec driver
  o [ATM]: Add Forerunner HE support
  o [ATM]: Forward port br2864 to 2.5.x
  o [ATM]: Clip locking and more atmvcc cleanup
  o [ATM]: assorted atm patches
  o [ATM] remove iovcnt from atm_skb skbs has (and has had for a while)
    scatter/gather support making the scatter gather in atm redundant. 
    the current iovcnt schme really isnt being used anyway typically.  
    the atm layer will need a little more work in the future to take
    advantage of the skb scatter/gather support.  this patch removes
    the iovcnt dependencies and gets the check for non linear skbs
    right.
  o [ATM]: Kill stray ATM_PDU_OVHD reference in lec.c
  o [ATM]: Make he driver code more palatable
  o [ATM]: HE and IPHASE driver fixes
  o [ATM]: Make clip modular
  o [ATM]: Fix module handling in USB speedtouch driver
  o [ATM]: Add refcounting to atmdev
  o [ATM]: Allow ATM to be loaded as a module
  o [ATM]: Fix modular CLIP
  o [ATM]: Need to use try_module_get not __module_get

Chris Wright:
  o [RXRPC]: Put file_operations THIS_OWNER in correct place

Christoph Hellwig:
  o split private and public scsi headers
  o kill scsi_dump_status
  o kill pcmcia driver bind_info horror
  o use scsi_report_bus_reset() in scsi_erroc.c
  o fix scsi_debug compile warning
  o remove dead struct scsi_device members
  o remove dead scsi_cmnd members
  o scsi_requeuest_fn
  o move max_sectors intitalization fully to scsi_register
  o Re: unchecked_isa_dma on sparcv9
  o nuke some superflous externs
  o update NCR_D700 for new-style probing
  o remove scsi_device proc printing from drivers
  o move all host templates into .c files
  o remove scsi_slave_attach/scsi_slave_detach
  o first batch of shost sysfs fixes
  o rationalize scsi_queue_next & friends
  o [SLIP]: Move over to initcalls
  o [NET]: Switch x25_asy over to initcalls
  o some warning fixes
  o fix the aacraid merge a bit more
  o scsi_report_device_reset
  o consolidate devlist handling in a single file
  o switch sb1000 to new style net init & pnp
  o two more templates in headers
  o [XFS] merge Steve's sync changes over to 2.5
  o [XFS] avoid sleep_on in the sync code
  o [XFS] Fix compile warning on my iBook
  o [XFS] simplify memory allocation code big time
  o [XFS] Use __GFP_NORETRY in pagebuf readahead code
  o [NET]: Fix dev_load for !CONFIG_KMOD
  o [NET]: Switch comx over to initcalls
  o do_fork updates for ppc
  o [NET]: Clean up the divert ifdef mess
  o [NET]: Make dv_init an initcall
  o [NET]: Switch arcnet over to initcalls
  o [NET]: Convert madgemc to initcalls
  o make vt_ioctl ix86isms explicit
  o wireless pcmcia updates

Chuck Lever:
  o the recently-applied patch to fix the rpc_show_tasks() Oops is
    incomplete

Corey Minyard:
  o IPMI update

Daniel McNeil:
  o [IPV6]: Missing kmem_cache_destroy calls

Dave Jones:
  o [CPUFREQ] Fix powernow-k7 hang
  o [AGPGART] Hammer GART can use generic enable routines now
  o [AGPGART] intel agp init cleanups
  o [AGPGART] Remove unneeded enums from intel gart driver
  o [AGPGART] Remove unused ALi enums
  o [AGPGART] Remove stale comment
  o [AGPGART] Fix typo in via-agp. s/PM400/P4M400/
  o [AGPGART] Remove useless enums from serverworks gart driver
  o [AGPGART] Remove unneeded enums from AMD k7 gart driver
  o [AGPGART] More setup routine -> static struct conversions
  o [AGPGART] Replace enum users with own methods
  o [AGPGART] Merge NVIDIA nForce / nForce2 AGP driver
  o [AGPGART] Makefile cleanups
  o [AGPGART] Remove unneeded settings of bridge->type
  o [AGPGART] Add symbolic constants for AGP mode setting
  o [AGPGART] Add more defines to kill off hardcoded values
  o [AGPGART] Don't configure agp bridges more than once if there is >1
    of them
  o [AGPGART] use symbols instead of hardcoded values in generic-3.0
    Lots more work to do here.
  o [AGPGART] Convert several functions to return void
  o [AGPGART] Fall back to non-isochronous xfers if setting up
    isochronous xfers fails
  o [AGPGART] Fix typo that stopped nvidia GART driver being built
  o [AGPGART] EXPORT_SYMBOL cleanups. Also move the global_cache_flush
    routine to generic.c
  o [AGPGART] Move function description comments from headers to the
    code they document
  o [AGPGART] kdoc'ify some of the function header comments
  o [AGPGART] Move function prototypes to headers
  o [AGPGART] Misc backend source tidy up
  o [AGPGART] Remove semaphore abstraction
  o [AGPGART] i855PM support from Bill Nottingham
  o [AGPGART] Fix kconfig dependancies
  o [AGPGART] fix macros that expect agp_bridge in global scope From
    Christoph Hellwig
  o [AGPGART] cleanup agp backend.c a bit More from Christoph.
  o [AGPGART] Nvidia GART cleanups
  o [AGPGART] Add back dummy module exit to keep things happy
  o [AGPGART] don't dereference agp_bridge in generic-3.0.c Yet more
    from Christoph..
  o [AGPGART] give all agpgart drivers a ->remove pci method
  o [AGPGART] proper agp_bridge_driver
  o [AGPGART] Fix Kconfig typo
  o [AGPGART] Shrink chipset_type enum (compile fix) Missing part of
    hch's last cset.
  o [AGPGART] Fix linking error
  o [CPUFREQ] Acer Aspire's have broken PST tables in one BIOS rev. DMI
    blacklist it
  o [AGPGART] Add some debugging printk's. Based on Linus' earlier
    patch
  o [CPUFREQ] Remove not needed ;'s from macro definitions
  o [AGPGART] Bulletproofing. NULL ptrs after freeing them
  o [AGPGART] Remove duplicate code in i810/i830 alloc_by_type
    functions
  o [AGPGART] Fix incorrect type warning
  o [AGPGART] Move debugging macros to header so they can be used in
    other parts of agpgart
  o [AGPGART] more kconfig cleanups
  o [AGPGART] Kill off some typedefs
  o [AGPGART] missing %p in debug printk
  o [AGPGART] Turn on debugging printks for a while
  o [AGPGART] Intel I875P support
  o [AGPGART] Disable debugging printk's again
  o [AGPGART] Skip devices with no AGP headers sooner
  o [AGPGART] Store agp revision in agp_bridge struct
  o [AGPGART] Work around AMD 8151 errata
  o [AGPGART] Only enable isochronous transfers on AGP3.5 chipsets
  o [AGPGART] Remove unneeded exports
  o [AGPGART] Remove duplicate copying of ->chipset in agp_copy_info()
  o [AGPGART] death of generic-3.0.c  = folded into generic.c
  o [AGPGART] Add proper AGP3 initialisation routine
  o [AGPGART] Make sure we don't poke reserved bits when enabling agp
    v3
  o [AGPGART] Add missing #defines from last checkin
  o [AGPGART] Use symbolic defines for isoch registers in isoch code
  o [AGPGART] CodingStyle nitpicks for isoch.c
  o [AGPGART] Make the agp 3.5 use the agp3 code for enabling, leaving
    just the isoch stuff in isoch.c
  o [AGPGART] add checks to agp_copy_info() before dereferencing
  o [DRM] Intel i8xx DRM modules are dependant on their AGP
    counterparts
  o [CPUFREQ] missing export compile fix for powernow-k7
  o [AGPGART] PPC Uninorth support
  o [AGPGART] Move AGP PM to individual drivers
  o [AGPGART] Add printk's to error paths of agp_add_bridge
  o [AGPGART] Remove duplicated masking routines, replace with
    agp_generic_mask_memory()
  o [AGPGART] Whitespace/CodingStyle cleanups
  o [NETROM]: Fix netdevice leak, from 2.4.x
  o Fix types on inflate.c constants
  o Preemption fixes for x86 MSR driver
  o Avoid ide-scsi from starting DMA too soon
  o i8253 locking
  o sx memleak
  o Fix ISDN return types
  o Fix standards compliance bugs in the tty layer
  o pcwatchdog firmware memory leak
  o iphase fix
  o ASUS P4B SMBus quirks
  o typo
  o Fix pnpbios switch
  o copy_to_user check for sgiserial
  o fix module-init-tools ver_linux problem
  o Shorten rcu_check_quiescent_state
  o byte counters for mkiss
  o shorten rclan debug output
  o i810 no codec fix
  o shrink zonelists
  o [AGPGART] pci_driver structures must remain valid while they are
    registered
  o [AGPGART] nForce driver needs its own insert/remove routines
  o [AGPGART] Fix oops in VIA initialisation
  o [AGPGART] Add support for VIA K8T400M GART
  o [AGPGART] Improve Kconfig
  o [AGPGART] agp_3_5_enable() doesn't need mode parameter
  o [AGPGART] Sanity check (and fix up broken) AGP modes when in AGP
    3.0 mode
  o [AGPGART] Log broken applications that pass crap flags so they can
    be fixed
  o [AGPGART] Skip nonisoch setup if isoch setup was successful
  o [AGPGART] Silly typo that put tried to put things into a impossible
    x16 mode
  o [AGPGART] PPC compile fix
  o [AGPGART] Remove duplicated fast writes test
  o [AGPGART] sanity check printk's
  o [AGPGART] Rid AGP/DRM of more typedefs
  o [AGPGART] Make alpha AGP work again
  o Nuke stale comment from bmac
  o Age old cs89x0 register define 'fixes' ?
  o fix tlan 64bit check
  o xircom init cleanups
  o 3c505 printk levels
  o hamachi PCI DMA fix from 2.4
  o au1000 init cleanups

David Brownell:
  o USB: ehci i/o watchdog
  o USB Gadget API (1/6)
  o Net2280 driver (2/6)
  o USB "Gadget Zero" driver (3/6)
  o USB Ethernet Gadget (4/6)
  o USB Gadget string utility (5/6)
  o kbuild/kbuild for USB Gadgets (6/6)
  o USB: gadget cleanup of #ifdefs
  o USB: gadget zero, loopback config fix
  o USB gadget: net2280: dmachain off, zlp pio ok
  o more kbuild tweaks]
  o Fix big-endian USB gadget build
  o USB: rm debug printks in ehci and ohci
  o USB: fix for multiple definition of `usb_gadget_get_string'
  o USB: net2280 minor updates
  o USB: net2280, PPC fixes
  o USB: usbtest, talk to user mode "firmware"
  o USB: Fix machine lockup when unloading HC driver
  o USB: Fix machine lockup when unloading HC driver (part 2)
  o USB: SMP ehci-q.c 1010 BUG()
  o USB: disable usb device endpoints in more places
  o USB: bugfix endpoint state
  o USB: net2280, control requests can be deferred

David Jeffery:
  o ips 2.5 driver update [1/4] irq return update
  o ips 2.5 driver update [2/4] missing kfree and static init s
  o ips 2.5 driver update [3/4]: misc cleanups
  o ips 2.5 driver update [4/4]: use dev_printk

David Mosberger:
  o ia64: Fix typos/whitespace related to serial code
  o ia64: Patch by Alex Williamson: forward port of the 2.4 sba_iommu
  o ia64: Merge Alex Williamson's sba_iommu patch
  o ia64: Make sba_iommu get detected early enough again
  o ia64: Update platform INIT handler to print a backtrace
  o ia64: Export hp_acpi_csr_space() for modules
  o ia64: Consolidate backtrace printing in a single routine
    (ia64_do_show_stack())
  o ia64: Fix _raw_read_lock() to not switch text sections.  Tidy it up
    with the help of ia64_fetchadd() macro.  Ditto for
    _raw_read_unlock().
  o ia64: Patch by Arun Sharma: In brl_emu.c, a 64 bit value was being
    assigned to an int.
  o ia64: Improve spinlock code to handle contention in shared routine
    called with a special convention.  Various minor fixes for
    gcc-pre3.4.
  o ia64: Manual merge of Steve's spelling fixes
  o ia64: Manual merge of Bjorn Helgaas' sba_iommu patch to make it use
    seq_file
  o mca.c
  o ia64: Patch from Asit K. Mallick: fix a few places where
    last_fph_cpu wasn't updated and one place in the sigreturn path
    where the fph-owner wasn't set.
  o ia64: Prepare for GCC v3.4.  Sync with 2.5.69
  o ia64: Patch by John Marvin: Add virtual mem-map support
  o Add ia64 relocation types to elf.h and clean up

David S. Miller:
  o [NET]: Use dump_stack in neigh_destroy
  o [NET]: Fix typo in previous neighbour.c change
  o [ATM]: mpc.c warning fixes
  o [NETFILTER IPV6]: Fix warnings
  o USB speedtouch fix
  o [IPSEC]: Fix SADB_EALG_{3,}DESCBC values
  o [ATM]: Fix some CPP pasting in ambassador driver
  o [NETFILTER]: ip_nat_proto_{icmp,udp}.c need ip_nat_core.h
  o [IPV6]: Kill spurious module_{get,put}()
  o [BLUETOOTH]: Fix hci_usb build
  o [SPARC64]: Only use power interrupt when button property exists
  o [IPV6]: Remove illogical bug check in fib6_del
  o [IPV4/IPV6]: Set owner field in family ops
  o [ATM]: Fix build of HE driver
  o [IPV4]: Use time_{before,after}() and proper jiffies types in
    route.c
  o [IPV4]: Two minor errors in jiffies changes
  o [PKT_SCHED]: Kill iovcnt reference from sch_atm.c
  o [IPV4]: Fix expiration test in rt_check_expire
  o [MPLS]: Add ethernet protocol numbers
  o [NETFILTER]: Fix icmp_reply_translation args
  o [MPLS]: Add MPLS support to PPP
  o [SKFDDI]: Use SET_MODULE_OWNER
  o [IPV6]: Pass route attributes all the way down
  o [NETFILTER]: Fix ip_nat_core.c:manip_pkt return value checks
  o [XFRM]: Fix typos in xfrm_state_put() changes
  o [TCP]: NULL out newsk->owner in tcp_create_openreq_child()
  o [VLAN]: vlanproc.c needs module.h
  o [IPV4/IPV6]; Missing schedule_net() in inet{,6}_del_protocol
  o [NETFILTER]: Fix stale skb data pointer usage in ipv4 NAT
  o [IPV6]: Missing sk->family check in UDPv6 multicast handling
  o [BRLOCK]: Kill stray brlock.h references in sparc/sparc64 headers
  o [IPV6]: Fix two bugs in ip6_append_data changes
  o [NETFILTER]: ip_ct_gather_frags no longer needs to linearize
  o [PKT_SCHED]: sch_ingress.c does not need to linearize SKBs
  o [NETFILTER]: Teach ip_fw_compat and modules to handle non-linear
    SKBs
  o [IPV6]: Check output fragmentation using dst_pmtu not dev->mtu
  o [AIC7XXX]: Only build in biosparam function if actually used
  o [IPV6]: Fix ipv6_addr_copy warning in ah6.c
  o [SPARC64]: Update defconfig
  o [AF_KEY]: Force km.state to XFRM_STATE_DEAD in pfkey_msg2xfrm_state
  o [RTNETLINK]: extern __inline__ --> static inline
  o [TCP]: extern __inline__ --> static inline where appropriate
  o [IPV6]: extern __inline__ --> static inline
  o [IPV4]: Fix ip_finish_output extern decl
  o [AX25]: extern inline --> static inline
  o [NET]: dev_load extern inline --> static inline
  o [APPLETALK]: extern inline --> static inline
  o [PKT_SCHED]: extern inline --> static inline
  o [AF_UNIX]: extern inline --> static inline
  o [SUNHME]: Use PCI config space if hm-rev property does not exist
  o [NET]: Split out policy flow cache to be a generic facility
  o [ATM]: common.c needs linux/init.h
  o [ATM]: atm{pvc,svc}_exit cannot be __exit
  o [NET]: Regenerate flow cache hash rnd more sanely
  o [NET]: Hoplimit is a metric not a route attribute
  o [IPV4]: Respect hoplimit route metric
  o [NETFILTER]: Move skb_ip_make_writable symbol export
  o [IPV4]: Flush routing cache on sysctl_ip_default_ttl changes
  o [SPARC{32,64}]: Adjust for changed do_fork return value
  o [NET]: Fix netdevice unregister races
  o [NET]: More device register/unregister fixing
  o [NET]: Fix sock_fprog setsockopt compat handling.  Based upon patch
    from Andi Kleen
  o [NET]: Comment typo in net/core/dev.c, thanks akpm
  o [IPV4]: Fix route copying during redirects
  o [NET]: Use irqreturn_t in acenic driver
  o [NET]: Fix build warning in ns83820 driver
  o [NET]: Fix typo in ns83820 sysfs changes
  o [ATM]: Fix build after netdev sysfs changes
  o [NETFILTER]: Use proper printf format for size_t in ipt_owner.c
  o [NETFILTER]: Update ipt_physdev.c for match arg changes
  o [IPV6]: DST entry leak found by stanford checker
  o [IPV6]: Memory leak found by stanford checker
  o [NET]: In dst_alloc, do not assume layout of atomic_t
  o [IPV6]: Dont store pointers to in6_addrs in struct flowi
  o [IPV4]: Fix fib_hash performance problems with huge route tables
  o [NET]: Zap non-netdevice usage of SET_MODULE_OWNER
  o [TCP]: Move TCP_TWKILL_foo macro definitions into tcp_minisocks.c
  o [NET]: Kill SMP_TIMER_* users
  o [TIMERS]: No more SMP_TIMER_* users, kill it
  o [SPARC64]: Offer isdn/irda/telephony config options
  o [IRDA]: Protect IDA dma stuff with CONFIG_ISA
  o [SPARC64]: Update defconfig
  o [NET]: Invoke netdev_unregister_sysfs() outside of RTNL semaphore
  o [IPV4]: Use get_order instead of reimplementation
  o [FUTEX]: Fix kernel/compat.c after requeueing futex changes
  o [FUTEX]: Fix kernel/futex.c warning on 64-bit

Dean Gaudet:
  o better ali1563 integrated ethernet support

Douglas Gilbert:
  o blk SCSI_IOCTL_SEND_COMMAND

Duncan Sands:
  o USB speedtouch: replace yield()
  o USB speedtouch: add defensive memory barriers
  o USB speedtouch: remove stale code
  o USB speedtouch: spin_lock_irqsave -> spin_lock_irq in process
    context
  o USB speedtouch: spin_lock_irqsave -> spin_lock_irq in tasklets
  o USB speedtouch: remove useless NULL pointer checks
  o USB speedtouch: receive path micro optimization
  o USB speedtouch: verbose debugging
  o USB speedtouch: trivial whitespace and name changes
  o USB speedtouch: replace yield()
  o USB speedtouch: add defensive memory barriers
  o USB speedtouch: spin_lock_irqsave -> spin_lock_irq in process
    context
  o USB speedtouch: spin_lock_irqsave -> spin_lock_irq in tasklets
  o USB speedtouch: verbose debugging
  o USB speedtouch: remove stale code
  o USB speedtouch: use optimally sized reconstruction buffers
  o USB speedtouch: send path micro optimizations
  o USB speedtouch: kfree_skb -> dev_kfree_skb
  o USB speedtouch: remove useless NULL pointer checks
  o USB speedtouch: receive path micro optimization
  o USB speedtouch: receive code rewrite
  o USB speedtouch: set owner fields

Ernie Petrides:
  o ia64: fixes for semtimedop() ia32-compat handling

François Romieu:
  o USB: patch to fix up coding style violations

Geert Uytterhoeven:
  o USB: Big endian RTL8150
  o M68k IRQ API updates [1-20]
  o Ataflop fix
  o Atari Atyfb fixes
  o times must be unsigned long
  o M68k kill ide_ioreg_t
  o M68k pte_file
  o hosts.c missing config.h
  o M68k sys_ipc ENOSYS
  o m68k ptrace
  o dmasound resurrection
  o M68k IDE
  o IDE iops clean ups
  o Amifb updates
  o M68k raw I/O updates
  o Q40/Q60 IDE
  o HAVE_ARCH_GET_SIGNAL_TO_DELIVER warning
  o M68k wd33c93_{abort,host_reset}()
  o Atafb bug in #if 0 code
  o Obsolete include/asm-ppc/linux_logo.h

Gerd Knorr:
  o i2c #1/3: listify i2c core
  o i2c #2/3: add i2c_clients_command
  o i2c #3/3: add class field to i2c_adapter

Greg Kroah-Hartman:
  o i2c: fix oops on startup of it87 driver
  o i2c: fix up the MAINTAINERS i2c entry
  o USB: replace kdev_t with int in usb_interface structure, as only
    drivers with the USB major use it
  o Cset exclude:
    linux-usb@gemeinhardt.info|ChangeSet|20030429230539|30870
  o USB: vicam: fix bugs in writing to proc files that were found by
    the CHECKER project
  o PCI Hotplug: fix up the compaq driver to work properly again
  o PCI Hotplug: fix up the ibm driver to work properly again
  o PCI Hotplug: fix compiler warning in ibm driver
  o PCI Hotplug: fix up the acpi driver to work properly again
  o PCI Hotplug: fix dependancies for CONFIG_HOTPLUG_PCI_ACPI
  o PCI Hotplug: export the acpi_resource_to_address64 function, as the
    acpi pci hotplug driver needs it
  o i2c: fix compile error due to previous patches
  o USB: add usb class support for usb drivers that use the USB major
  o USB: converted usblp over to new usb_register_dev() changes
  o USB: converted mdc800 over to new usb_register_dev() changes
  o USB: converted scanner over to new usb_register_dev() changes
  o USB: converted dabusb over to new usb_register_dev() changes
  o USB: converted auerswald over to new usb_register_dev() changes
  o USB: converted brlvger over to new usb_register_dev() changes
  o USB: converted rio500 over to new usb_register_dev() changes
  o USB: converted usblcd over to new usb_register_dev() changes
  o USB: converted usb-skeleton over to new usb_register_dev() changes
  o USB: remove #include <linux/devfs_fs_kernel.h> from some drivers
    that do not need it
  o USB: converted hiddev over to new usb_register_dev() changes
  o USB: update my copyrights in a few locations
  o TTY: add tty class support for all tty devices
  o TTY: changes based on tty_register_device() paramater change
  o TTY: remove usb-serial sysfs dev file as it is now redundant
  o TTY: fix up lost devfs_mk_cdev change
  o USB: change core to use devfs_mk_cdev() instead of devfs_register()
  o USB: fix up compile error in tiglusb driver due to devfs_mk_cdev()
    changes
  o TTY: add lock to tty_dev_list, and handle tty names with more than
    one '/'
  o i2c: add i2c_adapter class support
  o i2c: register the i2c_adapter_driver so things link up properly in
    sysfs
  o driver core: Add driver symlink to class devices in sysfs
  o driver core: remove unneeded line in class code
  o i2c: piix4 driver: turn common error message to a debug level and
    rename the sysfs driver name
  o USB: fix jiffies warning in uss720.c
  o USB: fix break control for pl2303 driver
  o i2c: fix up i2c-dev driver based on previous core changes
  o USB: speedtch merge fixups by hand
  o PCI: add pci_get_dev() and pci_put_dev()
  o PCI: remove pci_insert_device() as no one uses it anymore

Greg Ungerer:
  o return valid vma from get_user_pages for non-MMU systems
  o fix cache settings for m68knommu 5407 CLEOPATRA target
  o fix cache settings for m68knommu 5407 MOTOROLA target
  o fix ColdFire 5407 cache flushing
  o add dummy VMALLOC_ defines to m68knommu
  o update m68knommu link script with 5282 support
  o update m68knommu defconfig
  o lock xtime struct in m68knommu/ColdFire timers
  o calculate microsecond offsets for m68knommu/ColdFire timers
  o m68knommu check timer irq pending
  o m68knommu: add configuration options for ColdFire 5282 support
  o m68knommu: ColdFire 5282 support Makefile changes
  o m68knommu: add ColdFire 5282 support setup
  o moew ColdFire 5282 support
  o add m68knommu/5282 specific Makefile
  o add m68knommu/5282 config init code
  o add m68knommu/5282 start up code
  o create SIM header definitions for ColdFire 5282
  o include SIM header for ColdFire 5282
  o add support for the DMA of the ColdFire 5282
  o create header support for the ColdFire 5282 PIT timer
  o add pit timer for m68knommu/5282 CPU support
  o rework timer code used for different m68knommu/ColdFire CPU's
  o add support for 5282 ColdFire to the ColdFire serial header
  o ColdFire serial driver support for 5282 ColdFire
  o allow FEC driver config to be used with ColdFire 5282
  o FEC driver updates to support the ColdFire 5282 CPU (header)
  o remove crt0_fixed.S from m68knommu DragonEngine2 target
  o fix m68knommu DragonEngine2 target setup code
  o remove crt0_himem.S from m68knommu DragonEngine2 target
  o single start file for m68knommu DragonEngine2 target
  o remove crt0_rom.S from m68knommu DragonEngine2 target
  o configure boot params for m68knommu
  o make common m68knommu/68328 specific ints.c
  o don't call 68328 specific int setup
  o don't call 68328 specific int setup (in 68VZ328)

Hanna V. Linder:
  o patch: remove unnecessary proc stuff from controller struct
  o tc_zs tty_driver add .owner field remove MOD_INC/DEC_USE_COUNT
  o specialix tty_driver add .owner field remove MOD_INC/DEC_USE_COUNT
  o stallion tty_driver add .owner field remove MOD_INC/DEC_USE_COUNT
  o serial_tx3912  tty_driver add .owner field remove
    MOD_INC/DEC_USE_COUNT
  o sh-sci tty_driver add .owner field remove MOD_INC/DEC_USE_COUNT
  o ser_a2232 tty_driver add .owner field remove MOD_INC/DEC_USE_COUNT
  o serial167 tty_driver add .owner field remove MOD_INC/DEC_USE_COUNT
  o rocket tty_driver add .owner field remove MOD_INC/DEC_USE_COUNT
  o sgi/char/sgiserial tty_driver add .owner field remove
    MOD_INC/DEC_USE_COUNT
  o rio  tty_driver add .owner field remove MOD_INC/DEC_USE_COUNT
  o riscom8 tty_driver add .owner field remove MOD_INC/DEC_USE_COUNT
  o pcxx tty_driver add .owner field remove MOD_INC/DEC_USE_COUNT
  o mxser tty_driver add .owner field remove MOD_INC/DEC_USE_COUNT
  o istallion  tty_driver add .owner field remove MOD_INC/DEC_USE_COUNT
  o moxa tty_driver add .owner field remove MOD_INC/DEC_USE_COUNT
  o ip2main tty_driver add .owner field remove MOD_INC/DEC_USE_COUNT
  o isicom tty_driver add .owner field remove MOD_INC/DEC_USE_COUNT
  o esp  tty_driver add .owner field remove MOD_INC/DEC_USE_COUNT
  o hvc_console tty_driver add .owner field remove
    MOD_INC/DEC_USE_COUNT
  o dz tty_driver add .owner field remove MOD_INC/DEC_USE_COUNT
  o cyclades tty_driver add .owner field remove MOD_INC/DEC_USE_COUNT
  o amiserial tty_driver add .owner field remove MOD_INC/DEC_USE_COUNT
  o macintosh/macserial  tty_driver add .owner field remove
    MOD_INC/DEC_USE_COUNT
  o isdn/capi  tty_driver add .owner field remove MOD_INC/DEC_USE_COUNT
  o vme_scc tty_driver add .owner field remove MOD_INC/DEC_USE_COUNT

Heiko Carstens:
  o set data direction in sd_synchronize_cache in sd.c

Herbert Xu:
  o [AF_KEY]: Zero out sadb_prop_reserved
  o [XFRM_USER]: Add XFRM_MSG_UPDPOLICY, analogue of SADB_X_SPDUPDATE

Hideaki Yoshifuji:
  o [IPV6]: Fix offset in ICMPV6_HDR_FIELD messages
  o [IPV^]: Use correct icmp6 type in ip6_pkt_discard
  o [MAINTAINERS/CREDITS]: Add entries for USAGI hackers
  o [IPV6]: Convert /proc/net/raw6 to seq_file
  o [NET]: Set file_operations->owner as appropriate
  o [NET]: nonet.c needs module.h
  o [IPV6]: ARCnet support, driver side
  o [IPV6]: ARCnet support, protocol side
  o [IPV6]: Fix RFC number in ipcomp6.c
  o [NET]: Misplaced description in ip-sysctl.txt
  o [IPV6]: Move NIP6 macro into general header
  o [IPV6]: Update RFC references
  o [IPV6]: Remove obsolete declaration in transp_v6.h
  o [IPV4]: Use seq_release_private(), kill ip_seq_release() since no
    longer used
  o [IPV4]: Dont erroneously print UDP6 sockets in /proc/net/udp
  o [IPV6]: procfs clean-up
  o [IPV4/6]: Common UDP procfs infrastructure
  o [IPV6]: Convert /proc/net/udp6 to seq_file
  o [IPV4/6]: Common TCP procfs infrastructure
  o [IPV6]: Convert /proc/net/tcp6 to seq_file

Ingo Molnar:
  o signal latency fixes
  o scheduler cleanup
  o sync wakeup on UP
  o Fix lost scheduler rebalances
  o fix do_fork() return value
  o support "requeueing" futexes
  o signal latency improvement

James Bottomley:
  o Fix NCR_D700 driver
  o Add .release template method to scsi_debug.c
  o fix syntax error in ncr53c8xx from hch conversion
  o fix missed conversion of to_scsi_host -> dev_to_shost in sim710
  o add missing asm/io.h to scsi/dc395x.c
  o Update aacraid to last drop on 2.4 from Alan Cox
  o Update aacraid from 2.4->2.5 semantics
  o sd.c spinup code can go into a wild loop
  o Correct typo in linux/scsi/scsi.h and introduce new
  o Fix thinko introduced into include/scsi/scsi.h
  o Fix use after free in scsi_host_put
  o do_fork fixes for voyager x86 subarch

James Morris:
  o [IPSEC]: Use xfrm_state_put in pfkey_msg2xfrm_state
  o [XFRM]: Make use of xfrm_state_hold()
  o [XFRM]: Use xfrm_pol_hold()
  o [IPSEC]: Implement proper IPIP tunnel handling for IPcomp
  o [CRYPTO]: Fix config dependencies
  o [IPV4]: Fix RFC number in ipcomp.c

James Simmons:
  o Console font size fix
  o Remove EDID parsing
  o Riva Framebuffer update
  o Framebuffer console fix

Jean Tourrilhes:
  o irq fixes for wavelan_cs/netwave_cs
  o Wireless Extension 16
  o WE-16 for Wavelan ISA driver
  o WE-16 for Wavelan Pcmcia driver
  o IrDA skb leak fixes
  o IrNET crasher
  o IrLAP address fix
  o owner in irtty-sir
  o Various IrDA drivers
  o irport fixes
  o smsc-ircc2 driver

Jeb J. Cramer:
  o TSO fix
  o Added ethtool test ioctl
  o Removed strong branded device ids
  o Added support for 82546 Quad-port adapter
  o Fixed LED coloring on 82541/82547 controllers
  o Miscellaneous code cleanup
  o Whitespace cleanup

Jeff Garzik:
  o [SCTP]: Fix missing Kconfig dependency
  o [bk] add useful tip to bk kernel howto
  o [netdvr tulip] nuke stale defines
  o [netdrvr bonding] add 802.3ad support
  o [netdrvr bonding] minor merge/kbuild fixes
  o [netdrvr tulip] fix bogus merges

Jeff Muizelaar:
  o [NET]: post-sysfs netdev cleanup

Jens Axboe:
  o bio_endio() increments bio->bi_sector
  o make MO drive work with ide-floppy/ide-cd
  o shrink deadline hash size
  o dynamic request allocation
  o bio walking code
  o ide minimum 48-bit support
  o remove ide-cd chatty errors
  o Fix scsi_ioctl command direction bits
  o ide tcq fixes
  o Always allocate sense buffer for block commands
  o elevator core update
  o bio splitting

John Levon:
  o OProfile: flush work queue on shutdown
  o OProfile: minimize sample error
  o OProfile: timer usage override
  o OProfile: fix stale comment
  o OProfile: fix d_path() usage

Jon Grimm:
  o [SCTP] Optimize SACK generation
  o [SCTP] Use Crypto API
  o [SCTP] Add wrappers for sctp with no crypto support
  o [SCTP] Various code cleanup
  o [SCTP] Enable SctpChecksumErrors stat
  o [SCTP] Add a generic csum_copy for sctp
  o [SCTP] short-circuit reassembly & ordering for best case
  o [SCTP]  Allow private to global association
  o [SCTP] Use GFP_ATOMIC, while we holding the local_addr_lock
  o [SCTP] Fix ipv6 addressing bug
  o [SCTP]  More typedef removals
  o [SCTP]  Track partially acked message for SEND_FAILED
  o [SCTP] Fix sctp_sendmsg error path when associate fails
  o [SCTP] Add some macros to clean up code
  o [SCTP]  Add SCTP_MAXSEG sockopt
  o [SCTP]  Add SFR-CACC support.  (Ardelle.Fan)
  o [SCTP] Fix regression in mark_missing.  (Ardelle.Fan)
  o [SCTP] Control chunk bundling
  o [SCTP] Make fragmented messages know how to SEND_FAIL themselves
  o [SCTP] Free up data chunks that don't get accepted by
    primitive_SEND
  o [SCTP] Add sinfo_timetolive support
  o [SCTP] Use put_user() in get_peer_addr_params (reported by
    yjf@standford.edu)
  o [SCTP] Support SCTP ECN on ipv6

Jonathan Corbet:
  o cpufreq class fix

Justin T. Gibbs:
  o Change the callback argument for aic brace option parsing to u_long
    to avoid casting problems with different architectures.
  o Aic7xxx and Aic79xx driver Update

Kazunori Miyazawa:
  o [IPV4]: Introduce ip6_append_data

Kochi Takayoshi:
  o ia64: don't waste irq vectors

Krishna Kumar:
  o [TCP]: Handle NLM_F_ACK in tcp_diag.c
  o [XFRM_USER]: Wrong use of RTM_BASE

Linus Torvalds:
  o Whee. Fix ancient mailing address
  o Make lib/inflate.c look remotely like ANSI C, so that it can be
    properly checked with the rest of the kernel.
  o Avoid using undefined preprocessor symbols: check CONFIG_MK7 with
    "defined()" rather than using it as a value.
  o Use "__attribute__" consistently
  o Allow external checkers to overrid the "cond_syscall()" macro
  o Support a "checking" mode for kernel builds, that runs a
    user-supplied source checker on all C files before compiling them.
  o Use the right CFLAGS for source checking. Fix grammar
  o Make aic7xxx driver use ANSI prototypes. My checker tool refuses to
    touch K&R C.
  o Annotate LDT system calls with user pointer annotations
  o Annotate x86 system calls with user pointer annotations
  o Fix mismatch between i387 user copy function declaration and
    definition.
  o Annotate IPC system calls with user pointer annotations
  o Annotate vm86_info as a pointer to user space
  o Bartlomiej says: 'Please revert this patch, it is unfinished.'
    We'll do it *after* IDE taskfile IO is done Cset exclude:
    axboe@suse.de|ChangeSet|20030511184946|49736
  o Use '#ifdef' to test for CONFIG_xxx variables, instead of depending
  o Add user pointer annotations
  o Use '#ifdef' to test for CONFIG_xxx variables, instead of depending
    on undefined preprocessor symbols evaluating to zero.
  o Add user pointer annotations to core sysctl files
  o Add user pointer annotations to socket, file IO and signal
    handling.
  o Add user pointer annotations to mtrr driver
  o Fix do_utimes() user pointer annotations
  o Make sys_open() declaration match definition
  o Don't use undefined preprocessor symbols in expressions
  o Remove extraneous NO_MATCH
  o Fix broken aic7xxx preprocessor conditional (that's not how C
    preprocessor expressions work, guys!)
  o Don't make the intel-AGP driver require an AGP capabilities
    pointer. The integrated graphics AGP things don't have one.
  o Add user pointer annotations to core filesystem routines
  o Make x86 user-copy have user pointer annotations to match
    declarations.
  o Add a few initial user pointer annotations to sound driver
  o Fix up thinko in nasty "NMI while debug while systenter" codepath.
  o Make request_module() take a printf-like vararg argument instead of
    a string
  o Use proper ANSI stype function declarations in definitions
  o Merge gamma driver from DRI CVS, and fix it up for 2.5.x changes
  o DRI CVS update
  o More files to ignore: mtools.conf
  o Make KOBJ_NAME_LEN bigger, since at least the ieee1394 code has bus
    ID's that are longer than 16 bytes.
  o Add 'strlcpy()' implementation
  o Make driver model use 'strlcpy()' to make sure that all names are
    NUL-terminated
  o Fix compile warning from Al's chardev cleanups
  o Make cdev infrastructure initialize early
  o Do a strlcat() to go with the strlcpy()
  o [NETLINK]: Use module_init() in netlink_dev.c
  o We need <linux/highmem.h> for PKMAP_BASE

Maksim Krasnyanskiy:
  o [Bluetooth] Add required infrastructure for socket module
    refcounting
  o [Bluetooth] L2CAP config req/rsp fixes
  o [Bluetooth] Detect and log error condition when first L2CAP
    fragment is too long
  o [Bluetooth] RFCOMM must wait for MSC exchange to complete before
    sending data

Manfred Spraul:
  o credits update

Marc Zyngier:
  o depca update (was Re: [Patch] DMA mapping API for Alpha)

Marcel Holtmann:
  o [Bluetooth] Compile fix for URB_ZERO_PACKET
  o [Bluetooth] Send the correct values in RPN response
  o [Bluetooth] Handle priority bits in parameter negotiation

Mark Haverkamp:
  o New aacraid driver fixed

Mark Hoffman:
  o i2c: Add SiS96x I2C/SMBus driver

Mark W. McClelland:
  o I2C: add more classes

Martin Schwidefsky:
  o s390: arch fixes
  o s390: inline assemblies
  o s390: module alias support
  o s390: steal lock support
  o s390: module count
  o s390: 31 bit compat
  o s390: block device drivers
  o s390: console device drivers
  o s390: tape device driver
  o s390: network device drivers

Matt Domsch:
  o Device Driver Dynamic PCI Device IDs
  o Shrink dynids feature set
  o PCI dynids - documentation fixes, id_table NULL check
  o pci.h whitespace cleanups
  o dynids: call driver_attach() when new IDs are added

Matt Porter:
  o PPC32: Allow lowmem size to be set even if we don't have HIGHMEM

Matthew Dharm:
  o USB: storage: generate BBB reset after abort
  o USB: storage: remove inline function

Matthew Wilcox:
  o [DLCI]: Use module_init and fix ioctl handling

Mikael Pettersson:
  o restore sysenter MSRs at APM resume

Mike Anderson:
  o scsi host sysfs support [1-4]
  o scsi_host sysfs updates scsi-misc-2.5 [1-2]
  o scsi_host sysfs updates fix release behaviour

Mitsuru Kanda:
  o [IPSEC]: Fix ipcomp header handling in ipv4 IPCOMP
  o [IPV6]: Add IPCOMP support
  o [CRYPTO]: Update deflate dependencies
  o [IPSEC]: Fix ipv4 ipcomp threshold calculation

Nathan Scott:
  o [XFS] Fix up error handling on the initial superblock read
  o [XFS] Fix up a pagebuf spelling mistake and a couple of whitespace
    botches
  o [XFS] V1 log tweak - fix log record length used when checking for a
    partial log record write during log recovery head/tail
    calculations.
  o [XFS] Large sector changes - fixup definition of xfs_agfl_t, and
    numerous changes to make log recovery respect the log device sector
    size.
  o [XFS] Small buftarg cleanup - keep code which pokes inside a
    buftarg all in
  o [XFS] Second part buftarg cleanup, don't poke inside a buftarg here
    anymore
  o [XFS] Remove a void* from the xfs_mount structure, move the log
    stripe mask field from the xfs_mount structure to the log structure
    (saves a couple
  o [XFS] Rationalise xlog_in_core2 definition, remove some ifdef
    __KERNEL__ code which is unnecessary in log recovery, clarify some
    recovery debug code.
  o [XFS] Make log recovery code style consistent with a/ itself and b/
    much of the rest of XFS.  Fix numerous crimes against whitespace.
  o [XFS] Fix two remaining indentation inconsistencies
  o [XFS] Remove some dead code

Neil Brown:
  o kNFSd: TCP nfsd connection hangs when partial record header is
    received
  o kNFSd: SVC sockets don't disable Nagle
  o kNFSd: RPC server need to know that TCP and UDP have different
    wspace functions
  o kNFSd: Set SOCK_NOSPACE when RPC server decides there is
    insufficient
  o kNFSd: Make sure an RPC socket is closed immediately when a server
    write fails
  o kNFSd: Fix #error message when bits are badly defined
  o kNFSd: Minor rearrangements in NFSv4 server code to prepare for
    mroe state management
  o kNFSd: NFSv4 open share state patch
  o kNFSd: Allow request for nfsv4 pseudo root to perform an upcall

Nicolas Dupeux:
  o USB: UNUSUAL_DEV for aiptek pocketcam

Nicolas Pitre:
  o [ARM PATCH] 1533/1: fix count when no preload support in copy_page
  o [ARM PATCH] 1531/1: optimized ffs/ffz/fls for ARMv5

Patrick Mansfield:
  o Compile fix for scsi_syms.c

Patrick McHardy:
  o [XFRM]: Fix typo in __xfrm4_find_acq
  o [NET]: Fix two bogus kfree(skb)

Patrick Mochel:
  o Driver model: doc updates
  o kobject: Add better debugging for failed registrations
  o sysfs: Rewrite binary file handling
  o kobject: Update Documentation
  o driver model: Set device's kset before calling kobject_add()
  o driver model: Define BUS_ID_SIZE based on KOBJ_NAME_LEN
  o driver model: Remove device_sem
  o driver model: Add resources to struct platform_device
  o driver model: Modify resource representation in struct
    platform_device

Paul Fulghum:
  o synclink update
  o n_hdlc update

Paul Mackerras:
  o i2c: i2c-keywest.c irq handler type
  o Update mesh.c and mac53c94.c drivers
  o [PPP]: Rest of compression module changes, oops
  o Update mac ethernet drivers
  o PPC32: Need to call wake_up_forked_process in SMP idle task setup
  o PPC32: Makefile cleanups, patch from Sam Ravnborg
  o PPC32: Further makefile updates from Sam Ravnborg
  o PPC32: Minor whitespace and ifdef fixes
  o PPC32: Better allocation of DMA-consistent memory on incoherent
    machines
  o PPC32: Fix the declaration of openpic_ipi_action()
  o PPC32: Use might_sleep() in kmap()
  o PPC32: More fixes for PCI on non-cache-coherent platforms
  o PPC32: Define a suitable value for PAGE_KERNEL_NOCACHE
  o Fix preempt on PPC32 - have to set PREEMPT_ACTIVE when preempting
    kernel stuff
  o PPC32: Export a couple of symbols needed by direct rendering
    modules
  o Fix mac adbhid driver
  o module owner for ppp_synctty.c
  o module refcounts for airport driver

Per Winkvist:
  o USB: more unusual_devs.h changes

Pete Zaitcev:
  o [SPARC]: Fix shadowing of global max_pfn, kill BOOTMEM_DEBUG
  o [SPARC]: Allow esp to use highmem_io on sparc32
  o [SPARC]: New compact show_regs format
  o [SPARC]: Keiths SMP patch #1
  o [SPARC]: Add ->release to ESP driver
  o [SPARC]: Update defconfig
  o [SPARC]: Sanitize BUG()
  o [SPARC]: Fix ptracing of syscalls
  o [SPARC]: Switch bitops to unsigned long

Peter Bergner:
  o Forward port of 2.4 ppc64 signal changes
  o Forward port of 2.4 ppc64 /proc/ppc64/systemcfg changes
  o Catch illegal FP use within the kernel since it can cause data
    integrity errors in userland code

Petr Vandrovec:
  o Fix potential runqueue deadlock

Randy Dunlap:
  o [NET]: Spelling/typo fixes in rtnetlink.h
  o [IPV6]: Convert /proc/net/rt6_stats to seq_file
  o [IPV6]: Fix typos in ip6_fib.c
  o [IPV6]: Use time_after() etc. for comparing jiffies
  o [IPV6]: Remove incorrect comment in ip6_fib.c

Richard Henderson:
  o [ALPHA] Fix titan_intr_nop for 2.5 irq api changes
  o [ALPHA] Fix single-step breakpoints
  o [ALPHA] Update for do_fork changes

Roland McGrath:
  o core dump psinfo.pr_sname letter fix

Roman Zippel:
  o kconfig check fixes

Russell King:
  o [ARM] Miscellaneous minor fixes
  o [PCMCIA] Add per-socket thread to process socket events
  o [ARM] Update a variety of ARM drivers to use irqreturn_t
  o [ARM] Allow CONFIG_PM to be enabled on all ARM platforms
  o [ARM PATCH] 1530/1: PXA2xx IRQ handling updates
  o [ARM] Fix timer interrupts to use irqreturn_t
  o [ARM] Add prefetch support for ARMv5
  o [ARM] Fix test_bit to return 0 or 1
  o [ARM] Remove static mappings for Integrator PS/2 ports
  o [ARM] switch ptrace to use an undefined instruction
  o [ARM] Convert more structure initialisers to C99 syntax
  o [ARM] Fix SA1100_ir irqreturn_t
  o [ARM] Fix RiscPC i2c drivers for device model
  o [ARM] Update Acorn platform scsi drivers
  o [ARM] Relocate ARM SCSI and Net drivers
  o [ARM] Update cyber2000fb.c
  o [ARM] Fixup yet another missing irqreturn_t
  o [ARM] Update Acorn IDE drivers
  o [ARM] Remove .devclass initialiser from sa1111ps2
  o [ARM] Fix time_after() warnings in ether1.c
  o [ARM] Fix DMA handler race condition
  o [ARM] do_fork() now returns the PID

Rusty Lynch:
  o PCI Hotplug: kernel-api docbook fix for now non-existant PCI
    hotplug

Rusty Russell:
  o [NETFILTER]: Fix Module Usage in ipchains and ipfwadm
  o [NETFILTER]: Make NAT code handle non-linear skbs
  o [NETFILTER]: Fix skb_checksum args in ip_nat_core.c
  o [NETFILTER]: Move ip_fw declarations into header file
  o [NETFILTER]: Move skb_ip_make_writable to netfilter.c
  o [NETFILTER]: Non-linear iptables: core code
  o [NETFILTER]: Linearize iptables matches
  o [NETFILTER]: Linearize iptables targets
  o [NETFILTER]: Make nat helper modules use symbols to force conntrack
    modules
  o [irda] module refcounts in irlan
  o const char* to char* update in console.h
  o reorganize for unreachable code
  o better debug macro safety
  o DMA-API typo
  o update the short description for BLK_DEV_HPT366
  o unreachable code in fs_intermezzo_methods.c
  o add help texts for sound_oss_Kconfig
  o remove unneeded #define LinuxVersionCode from eata.c
  o MAINTAINERS update for SN support
  o Remove unused GFP_DMA from include_sound_trident.h
  o unreachable code in drivers_media_video_cpia_pp.c
  o NAPI_HOWTO.txt typo + interrupt fix
  o Self-promotion and minor docs updates
  o missing release_region in drivers_cdrom_cm206.c
  o Better docs for boot-up code
  o proper APIC suspension
  o Allow for architectures to override
  o kernel_suspend.c compile warning
  o Make videodev_proc_destory() __exit
  o Cleanup in fs_devpts_inode.c
  o fs_autofs4_root.c unused variable
  o Typo in isofs_inode.c
  o sx tty_driver add .owner field remove MOD_INC_DEC_USE_COUNT

Sam Ravnborg:
  o Remove 'strchr' warning from reiserfs
  o kbuild: Get more focus on warnings

Scott Feldman:
  o Remove "Freeing alive device" warning
  o move e100_asf_enable under CONFIG_PM to avoid warning
  o Add ethtool parameter support
  o Add ethtool cable diag test
  o Add MDI/MDI-X status to ethtool reg dump
  o cleanup Tx resources before running ethtool diags
  o fixed stalled stats collection
  o VLAN configuration was lost after ethtool diags run
  o misc
  o full stop/start on ethtool set speed/duplex/autoneg

Seth Rohit:
  o ia64: enable 1G hugepage size for Mckinley

Sridhar Samudrala:
  o [SCTP] getsockname()/getpeername() support for TCP-style sockets
  o [SCTP] shutdown() support for TCP-style sockets
  o [SCTP] Handle accept() of a CLOSED association
  o [SCTP] Return a readable event when polling on a TCP-style
    listening socket with a non-empty accept queue.
  o [SCTP] sctp_sendmsg() updates for TCP-style sockets
  o [SCTP] Initialize missing ipv4 fields of a AF_INET6 accept socket
  o [SCTP] SO_LINGER socket option for TCP-style sockets
  o [SCTP] Use prepare_to_wait()/finish_wait() interfaces
  o net/socket: fix bug in sys_accept

Stefan Brandl:
  o USB: another usb storage addition

Stephen Hemminger:
  o [IPV4]: Replace explicit dev->refcount bumps with dev_hold
  o [NET]: Kill more direct references to netdev->refcnt
  o [SYSKONNECT]: /proc module handling fixup
  o [PKTGEN]: Module and dev cleanup
  o [IPV4/IPV6]: inetsw using RCU
  o [BRIDGE]: Bridge timer performance enhancement
  o [NET]: Network packet type using RCU
  o [BRLOCK]: Kill big reader locks, no longer used
  o [IPV4/IPV6]: synchronize_kernel --> synchronize_net
  o [NET]: Use SET_MODULE_OWNER in ns83820 driver
  o [NET]: sysfs support of network devices
  o [NET]: Add sysfs support to several net devices

Stephen Lord:
  o [XFS] Move xfs_syncd code into xfs_super.c which is the only place
    which uses it
  o [XFS] remove the excess ; which crept into the syncd thread
    somewhere and basically turned it off.

Steve French:
  o Fix cifs_show_options to display mount options in a way that is
    more consistent with other filesystems
  o Fix readlink of dfs junctions
  o Fix oops caused by lack of spinlock protection on some lists. Fix
    display

Steven Cole:
  o ia64: spelling fixes
  o Use '#ifdef' to test for CONFIG_xxx variables
  o more potentially undefined preprocessor symbols

Steven Whitehouse:
  o [DECNET]: Add netfilter subdir for decnet and add the routing
    grabulator
  o [FS]: Add seq_release_private and proc_net_fops_create helpers
  o [DECNET]: seq file conversions and fixes
  o [DECNET]: Decnet not obeying netdev locking (from
    shemminger@osdl.org)

Stéphane Eranian:
  o ia64: perfmon update

Todd Inglett:
  o fix cpuid to physical id needed in 2.5
  o Need to turn on RI immediately after we get control from firmware
    as well as when secondary cpus are started.

Torben Mathiasen:
  o PCI Hotplug: cpqphp 66/100/133MHz PCI-X support

Trond Myklebust:
  o Decrement the nr_unstable page state after the COMMIT RPC call
    completes instead of before. This ensures that writeback 
    WB_SYNC_ALL does wait on completion.
  o Fix typos in close-to-open cache consistency checking
  o Fix a TCP race: check whether or not the socket has been
    disconnected before we allow an RPC request to wait on a reply.
  o Don't use an RPC child process when reconnecting to a TCP server
  o Ensure that if we need to reconnect the socket, we also resend the
    entire RPC message
  o Add the sk->callback_lock spinlocks to the RPC socket callbacks in
    order to protect the socket from being released by one CPU while
    the other is in a soft interrupt.
  o Ensure that Lockd and the NSM (statd) clients always use privileged
    ports. Remove the existing code to temporarily raise privileges in
    fs/lockd/host.c, and use the new code in net/sunrpc/xprt.c
  o UDP and TCP zero copy code for the NFS client. The main interest

Vojtech Pavlik:
  o USB: Fix Kconfig for usb printers
  o USB: Make Olympus cameras work with usb-storage

Walter Harms:
  o USB: fixes kernel_thread

Zephaniah Hull:
  o i2c: it87 patch
  o I2C: Another it87 patch
  o I2C: Yet another it87 patch
  o I2C: And another it87 patch
  o I2C: And yet another it87 patch



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

* Re: Linux 2.5.70 (Compiler warnings)
  2003-05-27  2:08 Linux 2.5.70 Linus Torvalds
@ 2003-05-27  2:45 ` Udo A. Steinberg
  2003-05-27  3:09   ` YOSHIFUJI Hideaki / 吉藤英明
  2003-05-27  8:48 ` Linux 2.5.70 compile error DevilKin
                   ` (4 subsequent siblings)
  5 siblings, 1 reply; 55+ messages in thread
From: Udo A. Steinberg @ 2003-05-27  2:45 UTC (permalink / raw)
  To: Linux Kernel Mailing List

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

On Mon, 26 May 2003 19:08:45 -0700 (PDT) Linus Torvalds (LT) wrote:

LT> Summary of changes from v2.5.69 to v2.5.70
LT> ============================================
LT> Sam Ravnborg:
LT>   o kbuild: Get more focus on warnings

Hi,

Since this patch went into the kernel, I assume there is a sufficient interest
in fixing compiler warnings before 2.6. is released. So here comes my list of
gcc-3.3. warnings for kernel hackers to look into.

Regards,
-Udo.


fs/fat/inode.c: In function `fat_fill_super':
fs/fat/inode.c:803: warning: comparison is always true due to limited range of data type

fs/smbfs/proc.c: In function `smb_proc_setattr_unix':
fs/smbfs/proc.c:3044: warning: integer constant is too large for "long" type
fs/smbfs/proc.c:3045: warning: integer constant is too large for "long" type
fs/smbfs/proc.c:3046: warning: integer constant is too large for "long" type
fs/smbfs/proc.c:3047: warning: integer constant is too large for "long" type
fs/smbfs/proc.c:3048: warning: integer constant is too large for "long" type

fs/smbfs/ioctl.c: In function `smb_ioctl':
fs/smbfs/ioctl.c:36: warning: comparison is always false due to limited range of data type
fs/smbfs/ioctl.c:36: warning: comparison is always false due to limited range of data type
fs/smbfs/ioctl.c:36: warning: comparison is always false due to limited range of data type
fs/smbfs/ioctl.c:36: warning: comparison is always false due to limited range of data type

crypto/sha512.c:51: warning: integer constant is too large for "long" type
crypto/sha512.c:51: warning: integer constant is too large for "long" type
crypto/sha512.c:51: warning: integer constant is too large for "long" type
crypto/sha512.c:52: warning: integer constant is too large for "long" type
crypto/sha512.c:52: warning: integer constant is too large for "long" type
crypto/sha512.c:52: warning: integer constant is too large for "long" type
crypto/sha512.c:53: warning: integer constant is too large for "long" type
crypto/sha512.c:53: warning: integer constant is too large for "long" type
crypto/sha512.c:53: warning: integer constant is too large for "long" type
crypto/sha512.c:54: warning: integer constant is too large for "long" type
crypto/sha512.c:54: warning: integer constant is too large for "long" type
crypto/sha512.c:54: warning: integer constant is too large for "long" type
crypto/sha512.c:55: warning: integer constant is too large for "long" type
crypto/sha512.c:55: warning: integer constant is too large for "long" type
crypto/sha512.c:55: warning: integer constant is too large for "long" type
crypto/sha512.c:56: warning: integer constant is too large for "long" type
crypto/sha512.c:56: warning: integer constant is too large for "long" type
crypto/sha512.c:56: warning: integer constant is too large for "long" type
crypto/sha512.c:57: warning: integer constant is too large for "long" type
crypto/sha512.c:57: warning: integer constant is too large for "long" type
crypto/sha512.c:57: warning: integer constant is too large for "long" type
crypto/sha512.c:58: warning: integer constant is too large for "long" type
crypto/sha512.c:58: warning: integer constant is too large for "long" type
crypto/sha512.c:58: warning: integer constant is too large for "long" type
crypto/sha512.c:59: warning: integer constant is too large for "long" type
crypto/sha512.c:59: warning: integer constant is too large for "long" type
crypto/sha512.c:59: warning: integer constant is too large for "long" type
crypto/sha512.c:60: warning: integer constant is too large for "long" type
crypto/sha512.c:60: warning: integer constant is too large for "long" type
crypto/sha512.c:60: warning: integer constant is too large for "long" type
crypto/sha512.c:61: warning: integer constant is too large for "long" type
crypto/sha512.c:61: warning: integer constant is too large for "long" type
crypto/sha512.c:61: warning: integer constant is too large for "long" type
crypto/sha512.c:62: warning: integer constant is too large for "long" type
crypto/sha512.c:62: warning: integer constant is too large for "long" type
crypto/sha512.c:62: warning: integer constant is too large for "long" type
crypto/sha512.c:63: warning: integer constant is too large for "long" type
crypto/sha512.c:63: warning: integer constant is too large for "long" type
crypto/sha512.c:63: warning: integer constant is too large for "long" type
crypto/sha512.c:64: warning: integer constant is too large for "long" type
crypto/sha512.c:64: warning: integer constant is too large for "long" type
crypto/sha512.c:64: warning: integer constant is too large for "long" type
crypto/sha512.c:65: warning: integer constant is too large for "long" type
crypto/sha512.c:65: warning: integer constant is too large for "long" type
crypto/sha512.c:65: warning: integer constant is too large for "long" type
crypto/sha512.c:66: warning: integer constant is too large for "long" type
crypto/sha512.c:66: warning: integer constant is too large for "long" type
crypto/sha512.c:66: warning: integer constant is too large for "long" type
crypto/sha512.c:67: warning: integer constant is too large for "long" type
crypto/sha512.c:67: warning: integer constant is too large for "long" type
crypto/sha512.c:67: warning: integer constant is too large for "long" type
crypto/sha512.c:68: warning: integer constant is too large for "long" type
crypto/sha512.c:68: warning: integer constant is too large for "long" type
crypto/sha512.c:68: warning: integer constant is too large for "long" type
crypto/sha512.c:69: warning: integer constant is too large for "long" type
crypto/sha512.c:69: warning: integer constant is too large for "long" type
crypto/sha512.c:69: warning: integer constant is too large for "long" type
crypto/sha512.c:70: warning: integer constant is too large for "long" type
crypto/sha512.c:70: warning: integer constant is too large for "long" type
crypto/sha512.c:70: warning: integer constant is too large for "long" type
crypto/sha512.c:71: warning: integer constant is too large for "long" type
crypto/sha512.c:71: warning: integer constant is too large for "long" type
crypto/sha512.c:71: warning: integer constant is too large for "long" type
crypto/sha512.c:72: warning: integer constant is too large for "long" type
crypto/sha512.c:72: warning: integer constant is too large for "long" type
crypto/sha512.c:72: warning: integer constant is too large for "long" type
crypto/sha512.c:73: warning: integer constant is too large for "long" type
crypto/sha512.c:73: warning: integer constant is too large for "long" type
crypto/sha512.c:73: warning: integer constant is too large for "long" type
crypto/sha512.c:74: warning: integer constant is too large for "long" type
crypto/sha512.c:74: warning: integer constant is too large for "long" type
crypto/sha512.c:74: warning: integer constant is too large for "long" type
crypto/sha512.c:75: warning: integer constant is too large for "long" type
crypto/sha512.c:75: warning: integer constant is too large for "long" type
crypto/sha512.c:75: warning: integer constant is too large for "long" type
crypto/sha512.c:76: warning: integer constant is too large for "long" type
crypto/sha512.c:76: warning: integer constant is too large for "long" type
crypto/sha512.c:76: warning: integer constant is too large for "long" type
crypto/sha512.c:77: warning: integer constant is too large for "long" type
crypto/sha512.c:77: warning: integer constant is too large for "long" type
crypto/sha512.c: In function `sha512_init':
crypto/sha512.c:182: warning: integer constant is too large for "long" type
crypto/sha512.c:183: warning: integer constant is too large for "long" type
crypto/sha512.c:184: warning: integer constant is too large for "long" type
crypto/sha512.c:185: warning: integer constant is too large for "long" type
crypto/sha512.c:186: warning: integer constant is too large for "long" type
crypto/sha512.c:187: warning: integer constant is too large for "long" type
crypto/sha512.c:188: warning: integer constant is too large for "long" type
crypto/sha512.c:189: warning: integer constant is too large for "long" type
crypto/sha512.c: In function `sha384_init':
crypto/sha512.c:198: warning: integer constant is too large for "long" type
crypto/sha512.c:199: warning: integer constant is too large for "long" type
crypto/sha512.c:200: warning: integer constant is too large for "long" type
crypto/sha512.c:201: warning: integer constant is too large for "long" type
crypto/sha512.c:202: warning: integer constant is too large for "long" type
crypto/sha512.c:203: warning: integer constant is too large for "long" type
crypto/sha512.c:204: warning: integer constant is too large for "long" type
crypto/sha512.c:205: warning: integer constant is too large for "long" type

drivers/char/vt_ioctl.c: In function `do_kdsk_ioctl':
drivers/char/vt_ioctl.c:85: warning: comparison is always false due to limited range of data type
drivers/char/vt_ioctl.c:85: warning: comparison is always false due to limited range of data type
drivers/char/vt_ioctl.c: In function `do_kdgkb_ioctl':
drivers/char/vt_ioctl.c:211: warning: comparison is always false due to limited range of data type

drivers/char/keyboard.c: In function `k_fn':
drivers/char/keyboard.c:663: warning: comparison is always true due to limited range of data type

drivers/i2c/i2c-sensor.c: In function `i2c_detect':
drivers/i2c/i2c-sensor.c:54: warning: `__check_region' is deprecated (declared at include/linux/ioport.h:113)

drivers/ide/ide-probe.c: In function `hwif_check_region':
drivers/ide/ide-probe.c:642: warning: `__check_region' is deprecated (declared at include/linux/ioport.h:113)
drivers/ide/ide-probe.c:644: warning: `__check_region' is deprecated (declared at include/linux/ioport.h:113)

drivers/serial/8250.c: In function `serial8250_set_termios':
drivers/serial/8250.c:1428: warning: comparison is always false due to limited range of data type

arch/i386/boot/setup.S: Assembler messages:
arch/i386/boot/setup.S:165: Warning: value 0x37ffffff truncated to 0x37ffffff


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

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

* Re: Linux 2.5.70 (Compiler warnings)
  2003-05-27  2:45 ` Linux 2.5.70 (Compiler warnings) Udo A. Steinberg
@ 2003-05-27  3:09   ` YOSHIFUJI Hideaki / 吉藤英明
  2003-05-27  7:10     ` David S. Miller
  0 siblings, 1 reply; 55+ messages in thread
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2003-05-27  3:09 UTC (permalink / raw)
  To: us15, jmorris, davem; +Cc: linux-kernel, yoshfuji

In article <20030527044519.0014a289.us15@os.inf.tu-dresden.de> (at Tue, 27 May 2003 04:45:19 +0200), "Udo A. Steinberg" <us15@os.inf.tu-dresden.de> says:

> crypto/sha512.c:51: warning: integer constant is too large for "long" type
> crypto/sha512.c:51: warning: integer constant is too large for "long" type
:

Patch should be simple.

Index: linux25-LINUS/crypto/sha512.c
===================================================================
RCS file: /cvsroot/usagi/usagi-backport/linux25/crypto/sha512.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 sha512.c
--- linux25-LINUS/crypto/sha512.c	17 Jan 2003 02:47:13 -0000	1.1.1.1
+++ linux25-LINUS/crypto/sha512.c	27 May 2003 02:59:35 -0000
@@ -48,33 +48,33 @@
 }
 
 const u64 sha512_K[80] = {
-        0x428a2f98d728ae22, 0x7137449123ef65cd, 0xb5c0fbcfec4d3b2f,
-        0xe9b5dba58189dbbc, 0x3956c25bf348b538, 0x59f111f1b605d019,
-        0x923f82a4af194f9b, 0xab1c5ed5da6d8118, 0xd807aa98a3030242,
-        0x12835b0145706fbe, 0x243185be4ee4b28c, 0x550c7dc3d5ffb4e2,
-        0x72be5d74f27b896f, 0x80deb1fe3b1696b1, 0x9bdc06a725c71235,
-        0xc19bf174cf692694, 0xe49b69c19ef14ad2, 0xefbe4786384f25e3,
-        0x0fc19dc68b8cd5b5, 0x240ca1cc77ac9c65, 0x2de92c6f592b0275,
-        0x4a7484aa6ea6e483, 0x5cb0a9dcbd41fbd4, 0x76f988da831153b5,
-        0x983e5152ee66dfab, 0xa831c66d2db43210, 0xb00327c898fb213f,
-        0xbf597fc7beef0ee4, 0xc6e00bf33da88fc2, 0xd5a79147930aa725,
-        0x06ca6351e003826f, 0x142929670a0e6e70, 0x27b70a8546d22ffc,
-        0x2e1b21385c26c926, 0x4d2c6dfc5ac42aed, 0x53380d139d95b3df,
-        0x650a73548baf63de, 0x766a0abb3c77b2a8, 0x81c2c92e47edaee6,
-        0x92722c851482353b, 0xa2bfe8a14cf10364, 0xa81a664bbc423001,
-        0xc24b8b70d0f89791, 0xc76c51a30654be30, 0xd192e819d6ef5218,
-        0xd69906245565a910, 0xf40e35855771202a, 0x106aa07032bbd1b8,
-        0x19a4c116b8d2d0c8, 0x1e376c085141ab53, 0x2748774cdf8eeb99,
-        0x34b0bcb5e19b48a8, 0x391c0cb3c5c95a63, 0x4ed8aa4ae3418acb,
-        0x5b9cca4f7763e373, 0x682e6ff3d6b2b8a3, 0x748f82ee5defb2fc,
-        0x78a5636f43172f60, 0x84c87814a1f0ab72, 0x8cc702081a6439ec,
-        0x90befffa23631e28, 0xa4506cebde82bde9, 0xbef9a3f7b2c67915,
-        0xc67178f2e372532b, 0xca273eceea26619c, 0xd186b8c721c0c207,
-        0xeada7dd6cde0eb1e, 0xf57d4f7fee6ed178, 0x06f067aa72176fba,
-        0x0a637dc5a2c898a6, 0x113f9804bef90dae, 0x1b710b35131c471b,
-        0x28db77f523047d84, 0x32caab7b40c72493, 0x3c9ebe0a15c9bebc,
-        0x431d67c49c100d4c, 0x4cc5d4becb3e42b6, 0x597f299cfc657e2a,
-        0x5fcb6fab3ad6faec, 0x6c44198c4a475817,
+        0x428a2f98d728ae22ULL, 0x7137449123ef65cdULL, 0xb5c0fbcfec4d3b2fULL,
+        0xe9b5dba58189dbbcULL, 0x3956c25bf348b538ULL, 0x59f111f1b605d019ULL,
+        0x923f82a4af194f9bULL, 0xab1c5ed5da6d8118ULL, 0xd807aa98a3030242ULL,
+        0x12835b0145706fbeULL, 0x243185be4ee4b28cULL, 0x550c7dc3d5ffb4e2ULL,
+        0x72be5d74f27b896fULL, 0x80deb1fe3b1696b1ULL, 0x9bdc06a725c71235ULL,
+        0xc19bf174cf692694ULL, 0xe49b69c19ef14ad2ULL, 0xefbe4786384f25e3ULL,
+        0x0fc19dc68b8cd5b5ULL, 0x240ca1cc77ac9c65ULL, 0x2de92c6f592b0275ULL,
+        0x4a7484aa6ea6e483ULL, 0x5cb0a9dcbd41fbd4ULL, 0x76f988da831153b5ULL,
+        0x983e5152ee66dfabULL, 0xa831c66d2db43210ULL, 0xb00327c898fb213fULL,
+        0xbf597fc7beef0ee4ULL, 0xc6e00bf33da88fc2ULL, 0xd5a79147930aa725ULL,
+        0x06ca6351e003826fULL, 0x142929670a0e6e70ULL, 0x27b70a8546d22ffcULL,
+        0x2e1b21385c26c926ULL, 0x4d2c6dfc5ac42aedULL, 0x53380d139d95b3dfULL,
+        0x650a73548baf63deULL, 0x766a0abb3c77b2a8ULL, 0x81c2c92e47edaee6ULL,
+        0x92722c851482353bULL, 0xa2bfe8a14cf10364ULL, 0xa81a664bbc423001ULL,
+        0xc24b8b70d0f89791ULL, 0xc76c51a30654be30ULL, 0xd192e819d6ef5218ULL,
+        0xd69906245565a910ULL, 0xf40e35855771202aULL, 0x106aa07032bbd1b8ULL,
+        0x19a4c116b8d2d0c8ULL, 0x1e376c085141ab53ULL, 0x2748774cdf8eeb99ULL,
+        0x34b0bcb5e19b48a8ULL, 0x391c0cb3c5c95a63ULL, 0x4ed8aa4ae3418acbULL,
+        0x5b9cca4f7763e373ULL, 0x682e6ff3d6b2b8a3ULL, 0x748f82ee5defb2fcULL,
+        0x78a5636f43172f60ULL, 0x84c87814a1f0ab72ULL, 0x8cc702081a6439ecULL,
+        0x90befffa23631e28ULL, 0xa4506cebde82bde9ULL, 0xbef9a3f7b2c67915ULL,
+        0xc67178f2e372532bULL, 0xca273eceea26619cULL, 0xd186b8c721c0c207ULL,
+        0xeada7dd6cde0eb1eULL, 0xf57d4f7fee6ed178ULL, 0x06f067aa72176fbaULL,
+        0x0a637dc5a2c898a6ULL, 0x113f9804bef90daeULL, 0x1b710b35131c471bULL,
+        0x28db77f523047d84ULL, 0x32caab7b40c72493ULL, 0x3c9ebe0a15c9bebcULL,
+        0x431d67c49c100d4cULL, 0x4cc5d4becb3e42b6ULL, 0x597f299cfc657e2aULL,
+        0x5fcb6fab3ad6faecULL, 0x6c44198c4a475817ULL,
 };
 
 #define e0(x)       (RORu64(x,28) ^ RORu64(x,34) ^ RORu64(x,39))
@@ -83,24 +83,24 @@
 #define s1(x)       (RORu64(x,19) ^ RORu64(x,61) ^ (x >> 6))
 
 /* H* initial state for SHA-512 */
-#define H0         0x6a09e667f3bcc908
-#define H1         0xbb67ae8584caa73b
-#define H2         0x3c6ef372fe94f82b
-#define H3         0xa54ff53a5f1d36f1
-#define H4         0x510e527fade682d1
-#define H5         0x9b05688c2b3e6c1f
-#define H6         0x1f83d9abfb41bd6b
-#define H7         0x5be0cd19137e2179
+#define H0         0x6a09e667f3bcc908ULL
+#define H1         0xbb67ae8584caa73bULL
+#define H2         0x3c6ef372fe94f82bULL
+#define H3         0xa54ff53a5f1d36f1ULL
+#define H4         0x510e527fade682d1ULL
+#define H5         0x9b05688c2b3e6c1fULL
+#define H6         0x1f83d9abfb41bd6bULL
+#define H7         0x5be0cd19137e2179ULL
 
 /* H'* initial state for SHA-384 */
-#define HP0 0xcbbb9d5dc1059ed8
-#define HP1 0x629a292a367cd507
-#define HP2 0x9159015a3070dd17
-#define HP3 0x152fecd8f70e5939
-#define HP4 0x67332667ffc00b31
-#define HP5 0x8eb44a8768581511
-#define HP6 0xdb0c2e0d64f98fa7
-#define HP7 0x47b5481dbefa4fa4
+#define HP0 0xcbbb9d5dc1059ed8ULL
+#define HP1 0x629a292a367cd507ULL
+#define HP2 0x9159015a3070dd17ULL
+#define HP3 0x152fecd8f70e5939ULL
+#define HP4 0x67332667ffc00b31ULL
+#define HP5 0x8eb44a8768581511ULL
+#define HP6 0xdb0c2e0d64f98fa7ULL
+#define HP7 0x47b5481dbefa4fa4ULL
 
 static inline void LOAD_OP(int I, u64 *W, const u8 *input)
 {

-- 
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA

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

* Re: Linux 2.5.70 (Compiler warnings)
  2003-05-27  3:09   ` YOSHIFUJI Hideaki / 吉藤英明
@ 2003-05-27  7:10     ` David S. Miller
  0 siblings, 0 replies; 55+ messages in thread
From: David S. Miller @ 2003-05-27  7:10 UTC (permalink / raw)
  To: yoshfuji; +Cc: us15, jmorris, linux-kernel

   From: YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org>
   Date: Tue, 27 May 2003 12:09:54 +0900 (JST)

   In article <20030527044519.0014a289.us15@os.inf.tu-dresden.de> (at Tue, 27 May 2003 04:45:19 +0200), "Udo A. Steinberg" <us15@os.inf.tu-dresden.de> says:
   
   > crypto/sha512.c:51: warning: integer constant is too large for "long" type
   > crypto/sha512.c:51: warning: integer constant is too large for "long" type
   :
   
   Patch should be simple.
   
Applied, thank you.

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

* Linux 2.5.70 compile error
  2003-05-27  2:08 Linux 2.5.70 Linus Torvalds
  2003-05-27  2:45 ` Linux 2.5.70 (Compiler warnings) Udo A. Steinberg
@ 2003-05-27  8:48 ` DevilKin
  2003-05-27 13:05   ` William Lee Irwin III
  2003-05-27 16:58 ` Linux 2.5.70 Ricky Beam
                   ` (3 subsequent siblings)
  5 siblings, 1 reply; 55+ messages in thread
From: DevilKin @ 2003-05-27  8:48 UTC (permalink / raw)
  To: linux-kernel

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

On Tuesday 27 May 2003 04:08, Linus Torvalds wrote:
  CC      arch/i386/kernel/numaq.o
In file included from arch/i386/kernel/numaq.c:31:
include/asm/numaq.h:31:1: warning: "MAX_NUMNODES" redefined
In file included from include/linux/gfp.h:4,
                 from include/linux/slab.h:14,
                 from include/linux/percpu.h:4,
                 from include/linux/sched.h:30,
                 from include/linux/mm.h:4,
                 from arch/i386/kernel/numaq.c:27:
include/linux/mmzone.h:18:1: warning: this is the location of the previous 
definition
arch/i386/kernel/numaq.c: In function `initialize_physnode_map':
arch/i386/kernel/numaq.c:95: error: `physnode_map' undeclared (first use in 
this  function)
arch/i386/kernel/numaq.c:95: error: (Each undeclared identifier is reported 
only  once
arch/i386/kernel/numaq.c:95: error: for each function it appears in.)
make[2]: *** [arch/i386/kernel/numaq.o] Error 1
make[1]: *** [arch/i386/kernel] Error 2
make[1]: Leaving directory `/usr/src/linux-2.5.70'
make: *** [stamp-build] Error 2

Jan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+0yZgpuyeqyCEh60RAtKyAKCAdKBfpSpVvbAbcJn0rW8Mi/8/SgCeKQra
H68W1INRt+vtCwKcAEs6rvU=
=XkHu
-----END PGP SIGNATURE-----


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

* Re: Linux 2.5.70 compile error
  2003-05-27  8:48 ` Linux 2.5.70 compile error DevilKin
@ 2003-05-27 13:05   ` William Lee Irwin III
  2003-05-27 15:29     ` DevilKin-LKML
  0 siblings, 1 reply; 55+ messages in thread
From: William Lee Irwin III @ 2003-05-27 13:05 UTC (permalink / raw)
  To: DevilKin; +Cc: linux-kernel

On Tue, May 27, 2003 at 10:48:29AM +0200, DevilKin wrote:
> include/linux/mmzone.h:18:1: warning: this is the location of the previous 
> definition
> arch/i386/kernel/numaq.c: In function `initialize_physnode_map':
> arch/i386/kernel/numaq.c:95: error: `physnode_map' undeclared (first use in 
> this  function)
> arch/i386/kernel/numaq.c:95: error: (Each undeclared identifier is reported 
> only  once
> arch/i386/kernel/numaq.c:95: error: for each function it appears in.)
> make[2]: *** [arch/i386/kernel/numaq.o] Error 1
> make[1]: *** [arch/i386/kernel] Error 2
> make[1]: Leaving directory `/usr/src/linux-2.5.70'
> make: *** [stamp-build] Error 2

I suspect you're attempting to shoot yourself in the foot. .config?


-- wli

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

* Re: Linux 2.5.70 compile error
  2003-05-27 13:05   ` William Lee Irwin III
@ 2003-05-27 15:29     ` DevilKin-LKML
  2003-05-27 15:36       ` William Lee Irwin III
  2003-05-27 15:38       ` Sean Neakums
  0 siblings, 2 replies; 55+ messages in thread
From: DevilKin-LKML @ 2003-05-27 15:29 UTC (permalink / raw)
  To: William Lee Irwin III; +Cc: linux-kernel

On Tuesday 27 May 2003 15:05, William Lee Irwin III wrote:
> I suspect you're attempting to shoot yourself in the foot. .config?

Ah, quite. I saw NUMA was activated, and disabling it fixed my problem. Odd 
though, that it should become active just by doing a 'make oldconfig' with my 
2.7.69 config file...

Anywayz, it works, this kernel solves all my outstanding issues sofar (being 
mostly with the irda) so I'm happy :P

Jan
-- 
You look like a million dollars.  All green and wrinkled.


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

* Re: Linux 2.5.70 compile error
  2003-05-27 15:29     ` DevilKin-LKML
@ 2003-05-27 15:36       ` William Lee Irwin III
  2003-05-27 15:48         ` John Stoffel
  2003-05-27 15:38       ` Sean Neakums
  1 sibling, 1 reply; 55+ messages in thread
From: William Lee Irwin III @ 2003-05-27 15:36 UTC (permalink / raw)
  To: DevilKin-LKML; +Cc: linux-kernel

On Tuesday 27 May 2003 15:05, William Lee Irwin III wrote:
>> I suspect you're attempting to shoot yourself in the foot. .config?

On Tue, May 27, 2003 at 05:29:48PM +0200, DevilKin-LKML wrote:
> Ah, quite. I saw NUMA was activated, and disabling it fixed my problem. Odd 
> though, that it should become active just by doing a 'make oldconfig' with my 
> 2.7.69 config file...
> Anywayz, it works, this kernel solves all my outstanding issues sofar (being 
> mostly with the irda) so I'm happy :P

It should be even more obscure than that; CONFIG_X86_NUMAQ is basically
"you had _better_ have this machine and you had _better_ know what you're
doing even if you have one".

At any rate, one of us will look at making the option at least harder to
accidentally turn on.


-- wli

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

* Re: Linux 2.5.70 compile error
  2003-05-27 15:29     ` DevilKin-LKML
  2003-05-27 15:36       ` William Lee Irwin III
@ 2003-05-27 15:38       ` Sean Neakums
  2003-05-27 15:52         ` Martin J. Bligh
  1 sibling, 1 reply; 55+ messages in thread
From: Sean Neakums @ 2003-05-27 15:38 UTC (permalink / raw)
  To: linux-kernel

DevilKin-LKML <devilkin-lkml@blindguardian.org> writes:

> On Tuesday 27 May 2003 15:05, William Lee Irwin III wrote:
>> I suspect you're attempting to shoot yourself in the foot. .config?
>
> Ah, quite. I saw NUMA was activated, and disabling it fixed my
> problem. Odd though, that it should become active just by doing a
> 'make oldconfig' with my 2.7.69 config file...

I guess in the future, all boxes are NUMA.

-- 
Sean Neakums - <sneakums@zork.net>

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

* Re: Linux 2.5.70 compile error
  2003-05-27 15:36       ` William Lee Irwin III
@ 2003-05-27 15:48         ` John Stoffel
  2003-05-27 15:52           ` William Lee Irwin III
  2003-05-27 18:19           ` Roman Zippel
  0 siblings, 2 replies; 55+ messages in thread
From: John Stoffel @ 2003-05-27 15:48 UTC (permalink / raw)
  To: William Lee Irwin III; +Cc: DevilKin-LKML, linux-kernel


William> It should be even more obscure than that; CONFIG_X86_NUMAQ is
William> basically "you had _better_ have this machine and you had
William> _better_ know what you're doing even if you have one".

William> At any rate, one of us will look at making the option at
William> least harder to accidentally turn on.

I ran into this as well, since the 2.5.69-70 config entry is *really*
unclear on what you need to enter there, it's not in the standard
Y/N/M format for options.  For example:

    Kernel module loader (KMOD) [Y/n/?] y
  *
  * Processor type and features
  *
  Subarchitecture Type (PC-compatible, Voyager (NCR), NUMAQ (IBM/Sequent), Summit/EXA (IBM x440), Support for other sub-arch SMP systems with more than 8 CPUs, SGI 320/540 (Visual Workstation), Generic architecture (Summit, bigsmp, default)) [PC-compatible] (NEW) 


What the hell am I supposed to enter here?  This is just friggin ugly
and un-readable.  It should be cleaned up.  Or is it just that the
help entry is appended to the question improperly here?  That's sorta
what it looks like peering at it with my head turned to the left all
the way.

Are these choices all mutually exclusive?  Or can you build a kernel
which will run on all these machines?  Now that would be interesting
for a distro to have... not.  *grin*

John



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

* Re: Linux 2.5.70 compile error
  2003-05-27 15:38       ` Sean Neakums
@ 2003-05-27 15:52         ` Martin J. Bligh
  0 siblings, 0 replies; 55+ messages in thread
From: Martin J. Bligh @ 2003-05-27 15:52 UTC (permalink / raw)
  To: Sean Neakums, linux-kernel

> DevilKin-LKML <devilkin-lkml@blindguardian.org> writes:
> 
>> On Tuesday 27 May 2003 15:05, William Lee Irwin III wrote:
>>> I suspect you're attempting to shoot yourself in the foot. .config?
>> 
>> Ah, quite. I saw NUMA was activated, and disabling it fixed my
>> problem. Odd though, that it should become active just by doing a
>> 'make oldconfig' with my 2.7.69 config file...
> 
> I guess in the future, all boxes are NUMA.

However, in the future, all boxes are also not i386, so we're OK still ;-)

M.


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

* Re: Linux 2.5.70 compile error
  2003-05-27 15:48         ` John Stoffel
@ 2003-05-27 15:52           ` William Lee Irwin III
  2003-05-27 16:35             ` John Stoffel
  2003-05-27 18:19           ` Roman Zippel
  1 sibling, 1 reply; 55+ messages in thread
From: William Lee Irwin III @ 2003-05-27 15:52 UTC (permalink / raw)
  To: John Stoffel; +Cc: DevilKin-LKML, linux-kernel

On Tue, May 27, 2003 at 11:48:56AM -0400, John Stoffel wrote:
>   Subarchitecture Type (PC-compatible, Voyager (NCR), NUMAQ (IBM/Sequent), Summit/EXA (IBM x440), Support for other sub-arch SMP systems with more than 8 CPUs, SGI 320/540 (Visual Workstation), Generic architecture (Summit, bigsmp, default)) [PC-compatible] (NEW) 
> What the hell am I supposed to enter here?  This is just friggin ugly
> and un-readable.  It should be cleaned up.  Or is it just that the
> help entry is appended to the question improperly here?  That's sorta
> what it looks like peering at it with my head turned to the left all
> the way.

If you don't know, then just hit "enter".


On Tue, May 27, 2003 at 11:48:56AM -0400, John Stoffel wrote:
> Are these choices all mutually exclusive?  Or can you build a kernel
> which will run on all these machines?  Now that would be interesting
> for a distro to have... not.  *grin*

Yes, they're mutually exclusive. You can't build one that will run on
all those machines because the programming isn't done right for that.
But the generic architecture option will run on at least 3.


-- wli

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

* Re: Linux 2.5.70 compile error
  2003-05-27 15:52           ` William Lee Irwin III
@ 2003-05-27 16:35             ` John Stoffel
  2003-05-27 16:43               ` William Lee Irwin III
  0 siblings, 1 reply; 55+ messages in thread
From: John Stoffel @ 2003-05-27 16:35 UTC (permalink / raw)
  To: William Lee Irwin III; +Cc: John Stoffel, DevilKin-LKML, linux-kernel

>>>>> "William" == William Lee Irwin <wli@holomorphy.com> writes:

William> On Tue, May 27, 2003 at 11:48:56AM -0400, John Stoffel wrote:
>> Subarchitecture Type (PC-compatible, Voyager (NCR), NUMAQ (IBM/Sequent), Summit/EXA (IBM x440), Support for other sub-arch SMP systems with more than 8 CPUs, SGI 320/540 (Visual Workstation), Generic architecture (Summit, bigsmp, default)) [PC-compatible] (NEW) 
>> What the hell am I supposed to enter here?  This is just friggin ugly
>> and un-readable.  It should be cleaned up.  Or is it just that the
>> help entry is appended to the question improperly here?  That's sorta
>> what it looks like peering at it with my head turned to the left all
>> the way.

William> If you don't know, then just hit "enter".

Sure, I understand that, but what I'm really complaining about is the
text of the prompt.  When I do a 'make menuconfig' it's alot cleaner
and more understandable what's happening here.

Part of the problem is the specification in arch/i386/Kconfig, which I
think needs to be re-worked.  

In my case, I specified that the max number of CPUS is 2, since I only
have a dual CPU box.  So it's not a BIGCPU box.  Not sure how to make
this change... I'll have to find some time and play with this.

William> Yes, they're mutually exclusive. You can't build one that
William> will run on all those machines because the programming isn't
William> done right for that.  But the generic architecture option
William> will run on at least 3.

I see that when I dod the menuconfig, it's not clear at all when
running oldconfig.

John

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

* Re: Linux 2.5.70 compile error
  2003-05-27 16:35             ` John Stoffel
@ 2003-05-27 16:43               ` William Lee Irwin III
  2003-05-27 17:50                 ` John Stoffel
  0 siblings, 1 reply; 55+ messages in thread
From: William Lee Irwin III @ 2003-05-27 16:43 UTC (permalink / raw)
  To: John Stoffel; +Cc: DevilKin-LKML, linux-kernel

"William" == William Lee Irwin <wli@holomorphy.com> writes:
William> If you don't know, then just hit "enter".

On Tue, May 27, 2003 at 12:35:38PM -0400, John Stoffel wrote:
> Sure, I understand that, but what I'm really complaining about is the
> text of the prompt.  When I do a 'make menuconfig' it's alot cleaner
> and more understandable what's happening here.
> Part of the problem is the specification in arch/i386/Kconfig, which I
> think needs to be re-worked.  
> In my case, I specified that the max number of CPUS is 2, since I only
> have a dual CPU box.  So it's not a BIGCPU box.  Not sure how to make
> this change... I'll have to find some time and play with this.

CONFIG_NR_CPUS should appear under the processor type and features menu.
I fixed sparse physical APIC ID wakeup, so setting it to 2 should be
fine now. If the configurator is hiding it from you, please contact
Roman Zippel, and in the meantime vi .config and search for NR_CPUS and
set that to the desired value. AFAIK the option is visible, but I've
not got unusual configs.


"William" == William Lee Irwin <wli@holomorphy.com> writes:
William> Yes, they're mutually exclusive. You can't build one that
William> will run on all those machines because the programming isn't
William> done right for that.  But the generic architecture option
William> will run on at least 3.

On Tue, May 27, 2003 at 12:35:38PM -0400, John Stoffel wrote:
> I see that when I dod the menuconfig, it's not clear at all when
> running oldconfig.

make oldconfig is not meant for those in need of explanations. It's
barely meant to be interactive if at all. menuconfig might be a better
configuration method for you.


-- wli

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

* Re: Linux 2.5.70
  2003-05-27 17:26   ` Linus Torvalds
@ 2003-05-27 16:48     ` Alan Cox
  2003-05-27 17:53       ` Linus Torvalds
  2003-05-27 18:09     ` Ricky Beam
  2003-05-28 15:58     ` Bill Davidsen
  2 siblings, 1 reply; 55+ messages in thread
From: Alan Cox @ 2003-05-27 16:48 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Ricky Beam, Linux Kernel Mailing List

On Maw, 2003-05-27 at 18:26, Linus Torvalds wrote:
> On Tue, 27 May 2003, Ricky Beam wrote:
> > 
> > Count up the number of drivers that haven't been updated to the current
> > PCI, hotplug, and modules interfaces.
> 
> Tough. If people don't use them, they don't get supported. It's that easy.

Its also a lot easier to update them once the core stops changing! There
are some things I worry about - the bio splitting has to be resolved,
IDE raid can't happen until that occurs and I'm also waiting for the IDE
taskfile stuff/bio splitting bits to resolve so I can merge a load of
IDE updates to make things like SII IDE and newer HPT chips work in
2.5.x/2.6

Architectures are also normally just a sync up job and its again easier
to do once the core has stoppee changing.


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

* Re: Linux 2.5.70
  2003-05-27  2:08 Linux 2.5.70 Linus Torvalds
  2003-05-27  2:45 ` Linux 2.5.70 (Compiler warnings) Udo A. Steinberg
  2003-05-27  8:48 ` Linux 2.5.70 compile error DevilKin
@ 2003-05-27 16:58 ` Ricky Beam
  2003-05-27 17:26   ` Linus Torvalds
                     ` (2 more replies)
  2003-05-27 21:42 ` John Cherry
                   ` (2 subsequent siblings)
  5 siblings, 3 replies; 55+ messages in thread
From: Ricky Beam @ 2003-05-27 16:58 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Kernel Mailing List

On Mon, 26 May 2003, Linus Torvalds wrote:
>... to start the "pre-2.6" series ...

You're kidding, right?  2.5 is no where near ready to be called anything
like "2.6".  With an actual code freeze -- as in fix the shit that's broken,
non-functional, and/or incompletely implemented without adding any more
stuff or rebuilding entire subsystems as opposed to the standard Linus
"code freeze" that's much like a slushy in the 9th level of Hell (assuming
it gets there, it doesn't last long and really does no go) -- 2.5 is about
a year away from having the current code base fully functional and on it's
way to stable.

Count up the number of drivers that haven't been updated to the current
PCI, hotplug, and modules interfaces.

Take a look at the number of arch's that haven't seen much testing (and
in many respects are thus broken)... does anyone have a functional 2.5.70
sparc64 kernel?  I've built several but they're all too big to be booted
(i.e. over 3.5M, and yes, I've turned off everything possible.)

--Ricky



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

* Re: Linux 2.5.70
  2003-05-27 16:58 ` Linux 2.5.70 Ricky Beam
@ 2003-05-27 17:26   ` Linus Torvalds
  2003-05-27 16:48     ` Alan Cox
                       ` (2 more replies)
  2003-05-27 21:06   ` Andreas Boman
  2003-05-28  2:30   ` Daniel Phillips
  2 siblings, 3 replies; 55+ messages in thread
From: Linus Torvalds @ 2003-05-27 17:26 UTC (permalink / raw)
  To: Ricky Beam; +Cc: Kernel Mailing List


On Tue, 27 May 2003, Ricky Beam wrote:
> 
> Count up the number of drivers that haven't been updated to the current
> PCI, hotplug, and modules interfaces.

Tough. If people don't use them, they don't get supported. It's that easy.

The thing is, these things won't change before 2.6 (or at least a 
pre-2.6). When 2.6.0 comes out, and somebody notices that they haven't 
bothered to try the 2.5.x series, _then_ maybe some of those odd-ball 
drivers get fixed.

Or not. Some of them may be literally due for retirement, with users just 
running an old kernel on old hardware.

Btw, this is nothing new. It has _always_ been the case that a lot of 
people didn't use the latest stable kernel until it was released, and then 
they complained because the drivers they used weren't up to spec.

			Linus


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

* Re: Linux 2.5.70 compile error
  2003-05-27 16:43               ` William Lee Irwin III
@ 2003-05-27 17:50                 ` John Stoffel
  2003-05-27 17:56                   ` William Lee Irwin III
  2003-05-27 21:56                   ` Martin J. Bligh
  0 siblings, 2 replies; 55+ messages in thread
From: John Stoffel @ 2003-05-27 17:50 UTC (permalink / raw)
  To: William Lee Irwin III; +Cc: John Stoffel, DevilKin-LKML, linux-kernel

>>>>> "William" == William Lee Irwin <wli@holomorphy.com> writes:

William> "William" == William Lee Irwin <wli@holomorphy.com> writes:
William> If you don't know, then just hit "enter".

William> On Tue, May 27, 2003 at 12:35:38PM -0400, John Stoffel wrote:
>> Sure, I understand that, but what I'm really complaining about is the
>> text of the prompt.  When I do a 'make menuconfig' it's alot cleaner
>> and more understandable what's happening here.
>> Part of the problem is the specification in arch/i386/Kconfig, which I
>> think needs to be re-worked.  
>> In my case, I specified that the max number of CPUS is 2, since I only
>> have a dual CPU box.  So it's not a BIGCPU box.  Not sure how to make
>> this change... I'll have to find some time and play with this.

William> CONFIG_NR_CPUS should appear under the processor type and
William> features menu.

I must not have been clear enough in my rant, so let me rephrase it.  

Because I had already configured NR_CPUS=2, I'm not sure that I should
have even gotten the choice of X86_BIGSMP at all, since it's obviously
not valid in this case.

I'm really asking for the configuration specifications and
dependencies to be cleaned up, and maybe I'll try to do it myself and
send in the patch.  Right now I'm going to be trying 2.5.70-mm1 with a
patch for my ISA Cyclades board first.

So the real thrust of my posts before was:


The language and description used when running 'make oldconfig' and
trying to set the "X86_GENERICARCH" option is ugly and hard to
understand and doesn't match how it's shown in the 'make menuconfig'
settings.  

Sure, I realize that oldconfig is more a helper than a real
interface, but it still has warts that I'd like to fix or have
someone else fix if I can't do it myself.

Maybe the entire issue is really how do you do specify and constrain
inputs properly in this setup?

John

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

* Re: Linux 2.5.70
  2003-05-27 16:48     ` Alan Cox
@ 2003-05-27 17:53       ` Linus Torvalds
  2003-05-27 21:15         ` Hans Reiser
  0 siblings, 1 reply; 55+ messages in thread
From: Linus Torvalds @ 2003-05-27 17:53 UTC (permalink / raw)
  To: Alan Cox; +Cc: Ricky Beam, Linux Kernel Mailing List


On 27 May 2003, Alan Cox wrote:
> 
> Architectures are also normally just a sync up job and its again easier
> to do once the core has stoppee changing.

Indeed. I think its more the rule than the exception that non-x86 
architectures "get with the program" sometime during the stable release 
rather than before. There's just not a lot of incentive for the odd-ball 
architectures to care before the fact.

Would I prefer to have everything fixed by 2.6.0 (or even the pre-2.6 
kernels)? Sure, everybody would. But it's just a fact of life that we 
won't see people who care about the issues before that happens.

In fact, judging by past performance, a lot of things won't get fixed 
before the actual vendors have made _releases_ that use 2.6.x (and the 
first ones inevitably will have 2.4.x as a fall-back: that's only prudent 
and sane).

This is not just a core kernel issue - we've seen this with subsystems 
like ext3 and ReiserFS: they were "finished' and "stable", but what made 
them _really_ stable was a release or two on vendor kernels, and thousands 
of users.

			Linus


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

* Re: Linux 2.5.70 compile error
  2003-05-27 17:50                 ` John Stoffel
@ 2003-05-27 17:56                   ` William Lee Irwin III
  2003-05-27 21:56                   ` Martin J. Bligh
  1 sibling, 0 replies; 55+ messages in thread
From: William Lee Irwin III @ 2003-05-27 17:56 UTC (permalink / raw)
  To: John Stoffel; +Cc: DevilKin-LKML, linux-kernel

"William" == William Lee Irwin <wli@holomorphy.com> writes:
William> CONFIG_NR_CPUS should appear under the processor type and
William> features menu.

On Tue, May 27, 2003 at 01:50:37PM -0400, John Stoffel wrote:
> I must not have been clear enough in my rant, so let me rephrase it.  
> Because I had already configured NR_CPUS=2, I'm not sure that I should
> have even gotten the choice of X86_BIGSMP at all, since it's obviously
> not valid in this case.
> I'm really asking for the configuration specifications and
> dependencies to be cleaned up, and maybe I'll try to do it myself and
> send in the patch.  Right now I'm going to be trying 2.5.70-mm1 with a
> patch for my ISA Cyclades board first.

They're meant to specify system types, in particular APIC configurations.


On Tue, May 27, 2003 at 01:50:37PM -0400, John Stoffel wrote:
> So the real thrust of my posts before was:
> The language and description used when running 'make oldconfig' and
> trying to set the "X86_GENERICARCH" option is ugly and hard to
> understand and doesn't match how it's shown in the 'make menuconfig'
> settings.  
> Sure, I realize that oldconfig is more a helper than a real
> interface, but it still has warts that I'd like to fix or have
> someone else fix if I can't do it myself.
> Maybe the entire issue is really how do you do specify and constrain
> inputs properly in this setup?

No idea. Ask Roman Zippel.

My expectation is that we aren't going to make kernel configuration
safe for Aunt Tillie anytime in the near future.


-- wli

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

* Re: Linux 2.5.70
  2003-05-27 17:26   ` Linus Torvalds
  2003-05-27 16:48     ` Alan Cox
@ 2003-05-27 18:09     ` Ricky Beam
  2003-05-27 18:22       ` Jeff Garzik
                         ` (3 more replies)
  2003-05-28 15:58     ` Bill Davidsen
  2 siblings, 4 replies; 55+ messages in thread
From: Ricky Beam @ 2003-05-27 18:09 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Kernel Mailing List

On Tue, 27 May 2003, Linus Torvalds wrote:
>On Tue, 27 May 2003, Ricky Beam wrote:
>>
>> Count up the number of drivers that haven't been updated to the current
>> PCI, hotplug, and modules interfaces.
>
>Tough. If people don't use them, they don't get supported. It's that easy.
...

Allow me to clarify... I don't mind drivers not working.  I *do* mind
drivers emitting hundreds of warnings and errors because dozens of things
were changed and no one cared to update everything they broke.  In some
cases, fixing things may be simple (eg. someone removed or renamed a field
in a struct somewhere) and in others years of work my be required (eg.
the new module interface.)

In my opinion (as it was in the long long ago), everything in a "stable"
release should at least compile cleanly -- "working" comes later after
users have been conned into using it.

--Ricky



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

* Re: Linux 2.5.70 compile error
  2003-05-27 15:48         ` John Stoffel
  2003-05-27 15:52           ` William Lee Irwin III
@ 2003-05-27 18:19           ` Roman Zippel
  2003-05-27 18:40             ` Dave Jones
  2003-05-27 19:46             ` John Stoffel
  1 sibling, 2 replies; 55+ messages in thread
From: Roman Zippel @ 2003-05-27 18:19 UTC (permalink / raw)
  To: John Stoffel; +Cc: William Lee Irwin III, DevilKin-LKML, linux-kernel

Hi,

On Tue, 27 May 2003, John Stoffel wrote:

>   *
>   * Processor type and features
>   *
>   Subarchitecture Type (PC-compatible, Voyager (NCR), NUMAQ (IBM/Sequent), Summit/EXA (IBM x440), Support for other sub-arch SMP systems with more than 8 CPUs, SGI 320/540 (Visual Workstation), Generic architecture (Summit, bigsmp, default)) [PC-compatible] (NEW) 
> 
> 
> What the hell am I supposed to enter here?  This is just friggin ugly
> and un-readable.  It should be cleaned up.

I agree and I already fixed this here, so with the next update this will 
look like this:

Subarchitecture Type
> 1. PC-compatible (X86_PC)
  2. Voyager (NCR) (X86_VOYAGER)
  3. NUMAQ (IBM/Sequent) (X86_NUMAQ)
  4. Summit/EXA (IBM x440) (X86_SUMMIT)
  5. Support for other sub-arch SMP systems with more than 8 CPUs (X86_BIGSMP)
  6. SGI 320/540 (Visual Workstation) (X86_VISWS)
  7. Generic architecture (Summit, bigsmp, default) (X86_GENERICARCH) (NEW)
choice[1-7]: 

This has other advantages too, one can see now which options were newly 
added and the individual help texts are accessible.

bye, Roman


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

* Re: Linux 2.5.70
  2003-05-27 18:09     ` Ricky Beam
@ 2003-05-27 18:22       ` Jeff Garzik
  2003-05-27 18:31       ` Robert Love
                         ` (2 subsequent siblings)
  3 siblings, 0 replies; 55+ messages in thread
From: Jeff Garzik @ 2003-05-27 18:22 UTC (permalink / raw)
  To: Ricky Beam; +Cc: Linus Torvalds, Kernel Mailing List

On Tue, May 27, 2003 at 02:09:43PM -0400, Ricky Beam wrote:
> On Tue, 27 May 2003, Linus Torvalds wrote:
> >On Tue, 27 May 2003, Ricky Beam wrote:
> >>
> >> Count up the number of drivers that haven't been updated to the current
> >> PCI, hotplug, and modules interfaces.
> >
> >Tough. If people don't use them, they don't get supported. It's that easy.
> ...
> 
> Allow me to clarify... I don't mind drivers not working.  I *do* mind
> drivers emitting hundreds of warnings and errors because dozens of things
> were changed and no one cared to update everything they broke.  In some
> cases, fixing things may be simple (eg. someone removed or renamed a field
> in a struct somewhere) and in others years of work my be required (eg.
> the new module interface.)
> 
> In my opinion (as it was in the long long ago), everything in a "stable"
> release should at least compile cleanly -- "working" comes later after
> users have been conned into using it.

No.  Doing this hides bugs.

We use the compiler to make bugs and needing-work areas blindingly
obviously.  Your suggesting we make them less so.

	Jeff




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

* Re: Linux 2.5.70
  2003-05-27 18:09     ` Ricky Beam
  2003-05-27 18:22       ` Jeff Garzik
@ 2003-05-27 18:31       ` Robert Love
  2003-05-27 19:18       ` Adrian Bunk
  2003-05-28 16:08       ` Bill Davidsen
  3 siblings, 0 replies; 55+ messages in thread
From: Robert Love @ 2003-05-27 18:31 UTC (permalink / raw)
  To: Ricky Beam; +Cc: Linus Torvalds, Kernel Mailing List

On Tue, 2003-05-27 at 11:09, Ricky Beam wrote:

> In my opinion (as it was in the long long ago), everything in a "stable"
> release should at least compile cleanly -- "working" comes later after
> users have been conned into using it.

A lot of this will happen in 2.6-pre, prior to 2.6.0, do not worry.

A final stable release is still a few months off, although as Linus and
Alan have said even that does not mean perfection. But before 2.6.0 hits
the streets, 2.6-pre will mature a lot. This is how things work.

	Robert Love


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

* Re: Linux 2.5.70 compile error
  2003-05-27 18:19           ` Roman Zippel
@ 2003-05-27 18:40             ` Dave Jones
  2003-05-27 18:50               ` William Lee Irwin III
  2003-05-27 21:59               ` Martin J. Bligh
  2003-05-27 19:46             ` John Stoffel
  1 sibling, 2 replies; 55+ messages in thread
From: Dave Jones @ 2003-05-27 18:40 UTC (permalink / raw)
  To: Roman Zippel
  Cc: John Stoffel, William Lee Irwin III, DevilKin-LKML, linux-kernel

On Tue, May 27, 2003 at 08:19:39PM +0200, Roman Zippel wrote:

 > > What the hell am I supposed to enter here?  This is just friggin ugly
 > > and un-readable.  It should be cleaned up.
 > I agree and I already fixed this here, so with the next update this will 
 > look like this:
 > 
 > Subarchitecture Type
 > > 1. PC-compatible (X86_PC)
 >   2. Voyager (NCR) (X86_VOYAGER)
 >   3. NUMAQ (IBM/Sequent) (X86_NUMAQ)
 >   4. Summit/EXA (IBM x440) (X86_SUMMIT)
 >   5. Support for other sub-arch SMP systems with more than 8 CPUs (X86_BIGSMP)
 >   6. SGI 320/540 (Visual Workstation) (X86_VISWS)
 >   7. Generic architecture (Summit, bigsmp, default) (X86_GENERICARCH) (NEW)
 > choice[1-7]: 
 > 
 > This has other advantages too, one can see now which options were newly 
 > added and the individual help texts are accessible.

Given that 99% of users will be choosing option 1, it might be a
good thing to have the remaining options only shown if a
CONFIG_X86_SUBARCHS=y and have things default to option 1 if =n.

		Dave


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

* Re: Linux 2.5.70 compile error
  2003-05-27 18:40             ` Dave Jones
@ 2003-05-27 18:50               ` William Lee Irwin III
  2003-05-27 21:59               ` Martin J. Bligh
  1 sibling, 0 replies; 55+ messages in thread
From: William Lee Irwin III @ 2003-05-27 18:50 UTC (permalink / raw)
  To: Dave Jones, Roman Zippel, John Stoffel, DevilKin-LKML, linux-kernel

On Tue, May 27, 2003 at 08:19:39PM +0200, Roman Zippel wrote:
>> This has other advantages too, one can see now which options were newly 
>> added and the individual help texts are accessible.

On Tue, May 27, 2003 at 07:40:16PM +0100, Dave Jones wrote:
> Given that 99% of users will be choosing option 1, it might be a
> good thing to have the remaining options only shown if a
> CONFIG_X86_SUBARCHS=y and have things default to option 1 if =n.

I'll see about this once I get to looking at making CONFIG_X86_NUMAQ
harder to accidentally trip over (unless someone else does it first).


-- wli

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

* Re: Linux 2.5.70
  2003-05-27 18:09     ` Ricky Beam
  2003-05-27 18:22       ` Jeff Garzik
  2003-05-27 18:31       ` Robert Love
@ 2003-05-27 19:18       ` Adrian Bunk
  2003-05-28 16:08       ` Bill Davidsen
  3 siblings, 0 replies; 55+ messages in thread
From: Adrian Bunk @ 2003-05-27 19:18 UTC (permalink / raw)
  To: Ricky Beam; +Cc: Linus Torvalds, Kernel Mailing List

On Tue, May 27, 2003 at 02:09:43PM -0400, Ricky Beam wrote:
> 
> Allow me to clarify... I don't mind drivers not working.  I *do* mind
> drivers emitting hundreds of warnings and errors because dozens of things
> were changed and no one cared to update everything they broke.  In some
> cases, fixing things may be simple (eg. someone removed or renamed a field
> in a struct somewhere) and in others years of work my be required (eg.
> the new module interface.)

Many warnings are for problems that were already present in 2.4 or for
using deprecated (IOW: working) functions. It might be a thought to
probably disable deprecated warnings for stable kernel releases (read
2.6.0, 2.6.1,...) but it's not always a measurement for how far away we
are from 2.6. And besides, a full build of 2.4.20 with gcc 2.95 gives
you 103 warnings.

> In my opinion (as it was in the long long ago), everything in a "stable"
> release should at least compile cleanly -- "working" comes later after
> users have been conned into using it.

IMHO compiling and non-working (or worse: working but data-corrupting) 
is worse than non-compiling. It might be a good idea to let broken 
drivers depend on an (undefined) CONFIG_BROKEN, but this is only a minor 
detail with no influence on the 2.6 schedule.

> --Ricky

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


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

* Re: Linux 2.5.70 compile error
  2003-05-27 18:19           ` Roman Zippel
  2003-05-27 18:40             ` Dave Jones
@ 2003-05-27 19:46             ` John Stoffel
  1 sibling, 0 replies; 55+ messages in thread
From: John Stoffel @ 2003-05-27 19:46 UTC (permalink / raw)
  To: Roman Zippel
  Cc: John Stoffel, William Lee Irwin III, DevilKin-LKML, linux-kernel


Roman> I agree and I already fixed this here, so with the next update
Roman> this will look like this:

Thanks Roman!  This will look alot better and be more easily
understood, by Aunt Tillie or even an aware kernel hacker.  wli not
withstanding, making it readable doesn't imply we're wasting time.  

Roman> Subarchitecture Type
>> 1. PC-compatible (X86_PC)
Roman>   2. Voyager (NCR) (X86_VOYAGER)
Roman>   3. NUMAQ (IBM/Sequent) (X86_NUMAQ)
Roman>   4. Summit/EXA (IBM x440) (X86_SUMMIT)
Roman>   5. Support for other sub-arch SMP systems with more than 8 CPUs (X86_BIGSMP)
Roman>   6. SGI 320/540 (Visual Workstation) (X86_VISWS)
Roman>   7. Generic architecture (Summit, bigsmp, default) (X86_GENERICARCH) (NEW)
Roman> choice[1-7]: 

Roman> This has other advantages too, one can see now which options
Roman> were newly added and the individual help texts are accessible.

Very nice, this will be great to have.

John


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

* Re: Linux 2.5.70
  2003-05-27 16:58 ` Linux 2.5.70 Ricky Beam
  2003-05-27 17:26   ` Linus Torvalds
@ 2003-05-27 21:06   ` Andreas Boman
  2003-05-28  2:30   ` Daniel Phillips
  2 siblings, 0 replies; 55+ messages in thread
From: Andreas Boman @ 2003-05-27 21:06 UTC (permalink / raw)
  To: Ricky Beam; +Cc: linux-kernel

On Tue, 2003-05-27 at 12:58, Ricky Beam wrote:
<SNIP>
> Take a look at the number of arch's that haven't seen much testing (and
> in many respects are thus broken)... does anyone have a functional 2.5.70
> sparc64 kernel?  I've built several but they're all too big to be booted
> (i.e. over 3.5M, and yes, I've turned off everything possible.)
> --Ricky
> 

aboman@griffin:~> uname -a
Linux griffin 2.5.70 #1 Tue May 27 16:53:08 EDT 2003 sparc64 unknown unknown GNU/Linux

aboman@griffin:~> ls -lh /boot/vmlinux-2.5.70 
-rwxrwxr-x    1 root     root         2.6M May 27 16:57 /boot/vmlinux-2.5.70

regards, 
	Andreas


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

* Re: Linux 2.5.70
  2003-05-27 17:53       ` Linus Torvalds
@ 2003-05-27 21:15         ` Hans Reiser
  0 siblings, 0 replies; 55+ messages in thread
From: Hans Reiser @ 2003-05-27 21:15 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Alan Cox, Ricky Beam, Linux Kernel Mailing List

Linus Torvalds wrote:

>
>This is not just a core kernel issue - we've seen this with subsystems 
>like ext3 and ReiserFS: they were "finished' and "stable", but what made 
>them _really_ stable was a release or two on vendor kernels, and thousands 
>of users.
>
>  
>
I wish this wasn't true, but it was.  When I say something is stable, I 
mean that we have fixed every reported bug.

I have this hypothesis of software engineering which is that every order 
of magnitude increase in the number of users finds as many bugs as the 
previous order of magnitude increase.

With ReiserFS, I several times publicly said that it was stable, and for 
that order of magnitude of users it was, and then the order of magnitude 
changed and it wasn't....

With V4 we are going to benefit from an accumulation of testing scripts 
(and more experience at what we do plus less hurried code), and that 
will put us a few orders of magnitude farther ahead.

It will be a bit ironic that V4 is architected for greater data security 
with its atomic filesystem operations, and yet V3 will for quite some 
time offer greater data security in reality.

(V4 is currently being tuned for CPU consumption, and its VM 
interaction.  We have some fond hope of releasing in July.)

-- 
Hans



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

* Re: Linux 2.5.70
  2003-05-27  2:08 Linux 2.5.70 Linus Torvalds
                   ` (2 preceding siblings ...)
  2003-05-27 16:58 ` Linux 2.5.70 Ricky Beam
@ 2003-05-27 21:42 ` John Cherry
  2003-05-28 17:55   ` John Cherry
  2003-05-28  5:45 ` [PATCH] register_ioctl32_conversion symbol exports fix Andres Salomon
  2003-05-28 14:59 ` Linux 2.5.70 Paweł Gołaszewski
  5 siblings, 1 reply; 55+ messages in thread
From: John Cherry @ 2003-05-27 21:42 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Kernel Mailing List

ompile statistics: 2.5.70
Compiler: gcc 3.2.2
Script: http://www.osdl.org/archive/cherry/stability/compregress.sh

          bzImage       bzImage        modules
        (defconfig)  (allmodconfig) (allmodconfig)

2.5.70  7 warnings    10 warnings   1366 warnings
        0 errors       0 errors       57 errors

2.5.69  7 warnings    11 warnings   1366 warnings
        0 errors       0 errors       57 errors

2.5.68  7 warnings    11 warnings   1975 warnings
        0 errors       6 errors       60 errors

2.5.67  8 warnings    12 warnings   2136 warnings
        0 errors       6 errors       89 errros


Compile statistics have been for kernel releases from 2.5.46 to 2.5.70
at: www.osdl.org/archive/cherry/stability

Failure summary:

   drivers/block: 2 warnings, 1 errors
   drivers/char: 237 warnings, 4 errors
   drivers/isdn: 237 warnings, 8 errors
   drivers/media: 102 warnings, 5 errors
   drivers/mtd: 31 warnings, 1 errors
   drivers/net: 336 warnings, 6 errors
   drivers/scsi/aic7xxx: 0 warnings, 1 errors
   drivers/video/i810: 3 warnings, 4 errors
   drivers/video/matrox: 3 warnings, 10 errors
   drivers/video: 81 warnings, 17 errors
   sound/oss: 49 warnings, 3 errors
   sound: 5 warnings, 3 errors


Warning summary:


   drivers/atm: 36 warnings, 0 errors
   drivers/cdrom: 25 warnings, 0 errors
   drivers/hotplug: 1 warnings, 0 errors
   drivers/i2c: 3 warnings, 0 errors
   drivers/ide: 32 warnings, 0 errors
   drivers/md: 2 warnings, 0 errors
   drivers/message: 1 warnings, 0 errors
   drivers/pcmcia: 3 warnings, 0 errors
   drivers/scsi/aacraid: 1 warnings, 0 errors
   drivers/scsi/pcmcia: 4 warnings, 0 errors
   drivers/scsi/sym53c8xx_2: 1 warnings, 0 errors
   drivers/serial: 1 warnings, 0 errors
   drivers/telephony: 10 warnings, 0 errors
   drivers/usb: 13 warnings, 0 errors
   drivers/video/aty: 4 warnings, 0 errors
   drivers/video/sis: 3 warnings, 0 errors
   fs/afs: 1 warnings, 0 errors
   fs/cifs: 1 warnings, 0 errors
   fs/intermezzo: 1 warnings, 0 errors
   fs/lockd: 4 warnings, 0 errors
   fs/nfsd: 2 warnings, 0 errors
   fs/smbfs: 2 warnings, 0 errors
   net: 30 warnings, 0 errors
   security: 2 warnings, 0 errors
   sound/isa: 3 warnings, 0 errors
   sound/pci: 1 warnings, 0 errors
   sound/usb: 2 warnings, 0 errors



Other stability-related links:
   OSDL Stability page:
       http://osdl.org/projects/26lnxstblztn/results/
   Nightly linux-2.5 bk build:
       www.osdl.org/archive/cherry/stability/linus-tree/running.txt
   2.5 porting items:
       www.osdl.org/archive/cherry/stability/linus-tree/port_items.txt
   2.5 porting items history:
       www.osdl.org/archive/cherry/stability/linus-tree/port_history.txt

John




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

* Re: Linux 2.5.70 compile error
  2003-05-27 17:50                 ` John Stoffel
  2003-05-27 17:56                   ` William Lee Irwin III
@ 2003-05-27 21:56                   ` Martin J. Bligh
  1 sibling, 0 replies; 55+ messages in thread
From: Martin J. Bligh @ 2003-05-27 21:56 UTC (permalink / raw)
  To: John Stoffel, William Lee Irwin III; +Cc: DevilKin-LKML, linux-kernel

> The language and description used when running 'make oldconfig' and
> trying to set the "X86_GENERICARCH" option is ugly and hard to
> understand and doesn't match how it's shown in the 'make menuconfig'
> settings.  

Generic arch will take over half of the other arches when it's a bit 
better tested. Generic PC is, I believe, the default - if that's not
working, let us know. Otherwise, don't mess with the defaults if you
don't understand the question ;-)

M.


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

* Re: Linux 2.5.70 compile error
  2003-05-27 18:40             ` Dave Jones
  2003-05-27 18:50               ` William Lee Irwin III
@ 2003-05-27 21:59               ` Martin J. Bligh
  2003-05-27 23:40                 ` Dave Jones
                                   ` (2 more replies)
  1 sibling, 3 replies; 55+ messages in thread
From: Martin J. Bligh @ 2003-05-27 21:59 UTC (permalink / raw)
  To: Dave Jones, Roman Zippel
  Cc: John Stoffel, William Lee Irwin III, DevilKin-LKML, linux-kernel

>  > > What the hell am I supposed to enter here?  This is just friggin ugly
>  > > and un-readable.  It should be cleaned up.
>  > I agree and I already fixed this here, so with the next update this will 
>  > look like this:
>  > 
>  > Subarchitecture Type
>  > > 1. PC-compatible (X86_PC)
>  >   2. Voyager (NCR) (X86_VOYAGER)
>  >   3. NUMAQ (IBM/Sequent) (X86_NUMAQ)
>  >   4. Summit/EXA (IBM x440) (X86_SUMMIT)
>  >   5. Support for other sub-arch SMP systems with more than 8 CPUs (X86_BIGSMP)
>  >   6. SGI 320/540 (Visual Workstation) (X86_VISWS)
>  >   7. Generic architecture (Summit, bigsmp, default) (X86_GENERICARCH) (NEW)
>  > choice[1-7]: 
>  > 
>  > This has other advantages too, one can see now which options were newly 
>  > added and the individual help texts are accessible.
> 
> Given that 99% of users will be choosing option 1, it might be a
> good thing to have the remaining options only shown if a
> CONFIG_X86_SUBARCHS=y and have things default to option 1 if =n.

Please, not more layered config options! That just makes people who
want to enable the x440 or other alternative platform require fair
amounts of psychic power (maybe this can be fixed with a big fat help
message, but so can the current method).

If you're going hide the other options away so much, then the default
should be the generic arch, IMHO.

M.


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

* Re: Linux 2.5.70 compile error
  2003-05-27 21:59               ` Martin J. Bligh
@ 2003-05-27 23:40                 ` Dave Jones
  2003-05-28  3:20                   ` Martin J. Bligh
  2003-05-28  3:34                 ` William Lee Irwin III
  2003-05-28 22:08                 ` Bill Davidsen
  2 siblings, 1 reply; 55+ messages in thread
From: Dave Jones @ 2003-05-27 23:40 UTC (permalink / raw)
  To: Martin J. Bligh
  Cc: Roman Zippel, John Stoffel, William Lee Irwin III, DevilKin-LKML,
	linux-kernel

On Tue, May 27, 2003 at 02:59:23PM -0700, Martin J. Bligh wrote:

 > > Given that 99% of users will be choosing option 1, it might be a
 > > good thing to have the remaining options only shown if a
 > > CONFIG_X86_SUBARCHS=y and have things default to option 1 if =n.
 > 
 > Please, not more layered config options! That just makes people who
 > want to enable the x440 or other alternative platform require fair
 > amounts of psychic power (maybe this can be fixed with a big fat help
 > message, but so can the current method).

With all due respect, 'screw x440 et al'. The fact remains that a
majority of users won't even know what an x440 _is_, let alone
need to configure for one.  If someone has actually ended up with
one of those, I'd like to think they at least have enough clue to
know what it is they've just spent their megabucks on.		

 > If you're going hide the other options away so much, then the default
 > should be the generic arch, IMHO.

That's precisely what I was saying.  I think we're in agreement,
in a roundabout 'same but different' sort of way. I think.

		Dave


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

* Re: Linux 2.5.70
  2003-05-27 16:58 ` Linux 2.5.70 Ricky Beam
  2003-05-27 17:26   ` Linus Torvalds
  2003-05-27 21:06   ` Andreas Boman
@ 2003-05-28  2:30   ` Daniel Phillips
  2 siblings, 0 replies; 55+ messages in thread
From: Daniel Phillips @ 2003-05-28  2:30 UTC (permalink / raw)
  To: Ricky Beam, Linus Torvalds; +Cc: Kernel Mailing List

On Tuesday 27 May 2003 18:58, Ricky Beam wrote:
> On Mon, 26 May 2003, Linus Torvalds wrote:
> >... to start the "pre-2.6" series ...
>
> You're kidding, right?  2.5 is no where near ready to be called anything
> like "2.6".

Don't freak out too much - remember how long the -test series lasted last time 
(most of a year).  Hopefully it will be faster this time, but even twice as 
fast will still give people time to beat on their favorite features and 
drivers.

Regards,

Daniel

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

* Re: Linux 2.5.70 compile error
  2003-05-27 23:40                 ` Dave Jones
@ 2003-05-28  3:20                   ` Martin J. Bligh
  0 siblings, 0 replies; 55+ messages in thread
From: Martin J. Bligh @ 2003-05-28  3:20 UTC (permalink / raw)
  To: Dave Jones
  Cc: Roman Zippel, John Stoffel, William Lee Irwin III, DevilKin-LKML,
	linux-kernel

>  > Please, not more layered config options! That just makes people who
>  > want to enable the x440 or other alternative platform require fair
>  > amounts of psychic power (maybe this can be fixed with a big fat help
>  > message, but so can the current method).
> 
> With all due respect, 'screw x440 et al'. The fact remains that a
> majority of users won't even know what an x440 _is_, let alone
> need to configure for one.  If someone has actually ended up with
> one of those, I'd like to think they at least have enough clue to
> know what it is they've just spent their megabucks on.		

;-)
 
>  > If you're going hide the other options away so much, then the default
>  > should be the generic arch, IMHO.
> 
> That's precisely what I was saying.  I think we're in agreement,
> in a roundabout 'same but different' sort of way. I think.

OK, I think so ... I just think making the generic arch the default is
sufficient, without hiding things away under another menu where it's
harder to find ... if people don't understand the question, they should
just take the default. Frigging with the wording might help a bit ...
I think there's some way to force a hint to appear automatically like 
"if you don't know, use XXX".

M.


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

* Re: Linux 2.5.70 compile error
  2003-05-27 21:59               ` Martin J. Bligh
  2003-05-27 23:40                 ` Dave Jones
@ 2003-05-28  3:34                 ` William Lee Irwin III
  2003-05-28  6:11                   ` Martin J. Bligh
  2003-05-28  6:52                   ` Dave Jones
  2003-05-28 22:08                 ` Bill Davidsen
  2 siblings, 2 replies; 55+ messages in thread
From: William Lee Irwin III @ 2003-05-28  3:34 UTC (permalink / raw)
  To: Martin J. Bligh
  Cc: Dave Jones, Roman Zippel, John Stoffel, DevilKin-LKML, linux-kernel

At some point in the past, Dave Jones' attribution was stripped from:
>> Given that 99% of users will be choosing option 1, it might be a
>> good thing to have the remaining options only shown if a
>> CONFIG_X86_SUBARCHS=y and have things default to option 1 if =n.

On Tue, May 27, 2003 at 02:59:23PM -0700, Martin J. Bligh wrote:
> Please, not more layered config options! That just makes people who
> want to enable the x440 or other alternative platform require fair
> amounts of psychic power (maybe this can be fixed with a big fat help
> message, but so can the current method).
> If you're going hide the other options away so much, then the default
> should be the generic arch, IMHO.

Or better yet, remove all the #ifdefs, finish generalizing the APIC
code, and have nothing to configure at all. For 2.7 ...


-- wli

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

* [PATCH] register_ioctl32_conversion symbol exports fix
  2003-05-27  2:08 Linux 2.5.70 Linus Torvalds
                   ` (3 preceding siblings ...)
  2003-05-27 21:42 ` John Cherry
@ 2003-05-28  5:45 ` Andres Salomon
       [not found]   ` <20030528074701.GA17449@fs.tum.de>
  2003-05-28 14:59 ` Linux 2.5.70 Paweł Gołaszewski
  5 siblings, 1 reply; 55+ messages in thread
From: Andres Salomon @ 2003-05-28  5:45 UTC (permalink / raw)
  To: linux-kernel

I get the following error when compiling 2.5.70 for sparc64, using
gcc-3.3:


 CC      init/version.o
scripts/fixdep init/.version.o.d init/version.o 'gcc -Wp,-MD,init/.version.o.d -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -m64 -pipe -mno-fpu -mcpu=ultrasparc -mcmodel=medlow -ffixed-g4 -fcall-used-g5 -fcall-used-g7 -Wno-sign-compare -Wa,--undeclared-regs -finline-limit=100000 -fomit-frame-pointer -nostdinc -iwithprefix include    -DKBUILD_BASENAME=version -DKBUILD_MODNAME=version -c -o init/.tmp_version.o init/version.c' > init/.version.o.tmp; rm -f init/.version.o.d; mv -f init/.version.o.tmp init/.version.o.cmd
  LD      init/built-in.o
  LD      vmlinux
fs/built-in.o(*ABS*+0xb766971): In function `__crc_register_ioctl32_conversion':util.c: multiple definition of `__crc_register_ioctl32_conversion'
make: *** [vmlinux] Error 1


The problem is apparently register_ioctl32_conversion() is exported twice
for a few architectures:

./fs/compat.c:int register_ioctl32_conversion(unsigned int cmd, int (*handler)(unsigned int, unsigned int, unsigned long, struct file *))
./fs/compat.c:EXPORT_SYMBOL(register_ioctl32_conversion);
./arch/ppc64/kernel/ppc_ksyms.c:EXPORT_SYMBOL(register_ioctl32_conversion);
./arch/sparc64/kernel/sparc64_ksyms.c:EXPORT_SYMBOL(register_ioctl32_conversion);

Since compat.c is only built if CONFIG_COMPAT is defined, the entries in
${arch}_ksyms.c are incorrect (at the very least, they need to test for
this sort of thing).  I don't see the harm in removing the exports
altogether from the arch-specific stuff; so, that's what this patch does
(to both {,un}register_ioctl32_conversion).  Please apply (or correct me
;)




On Mon, 26 May 2003 19:08:45 -0700, Linus Torvalds wrote:
> 
> Ok, 
>  there's been too much delay between 69 and 70, but I was hoping to make 
> 70 the last "Linus only" release before getting together with Andrew and 
> figuring out how to start the "pre-2.6" series and more of a code slush. 
> 
[...]
>   o I2C: And another it87 patch
>   o I2C: And yet another it87 patch



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

* Re: Linux 2.5.70 compile error
  2003-05-28  3:34                 ` William Lee Irwin III
@ 2003-05-28  6:11                   ` Martin J. Bligh
  2003-05-28  7:43                     ` William Lee Irwin III
  2003-05-28  6:52                   ` Dave Jones
  1 sibling, 1 reply; 55+ messages in thread
From: Martin J. Bligh @ 2003-05-28  6:11 UTC (permalink / raw)
  To: William Lee Irwin III
  Cc: Dave Jones, Roman Zippel, John Stoffel, DevilKin-LKML, linux-kernel

> At some point in the past, Dave Jones' attribution was stripped from:
>>> Given that 99% of users will be choosing option 1, it might be a
>>> good thing to have the remaining options only shown if a
>>> CONFIG_X86_SUBARCHS=y and have things default to option 1 if =n.
> 
> On Tue, May 27, 2003 at 02:59:23PM -0700, Martin J. Bligh wrote:
>> Please, not more layered config options! That just makes people who
>> want to enable the x440 or other alternative platform require fair
>> amounts of psychic power (maybe this can be fixed with a big fat help
>> message, but so can the current method).
>> If you're going hide the other options away so much, then the default
>> should be the generic arch, IMHO.
> 
> Or better yet, remove all the #ifdefs, finish generalizing the APIC
> code, and have nothing to configure at all. For 2.7 ...

For the "commerical" options like Summit and bigsmp, I think this is an
option for 2.5 even, given some more testing. And then the wierdo arches
can be better hidden ;-)

M.


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

* Re: Linux 2.5.70 compile error
  2003-05-28  3:34                 ` William Lee Irwin III
  2003-05-28  6:11                   ` Martin J. Bligh
@ 2003-05-28  6:52                   ` Dave Jones
  1 sibling, 0 replies; 55+ messages in thread
From: Dave Jones @ 2003-05-28  6:52 UTC (permalink / raw)
  To: William Lee Irwin III, Martin J. Bligh, Roman Zippel,
	John Stoffel, DevilKin-LKML, linux-kernel

On Tue, May 27, 2003 at 08:34:59PM -0700, William Lee Irwin III wrote:

 > Or better yet, remove all the #ifdefs, finish generalizing the APIC
 > code, and have nothing to configure at all. For 2.7 ...

Yes, even better. Especially for distros. Andi did some work in
this area, but there is still work to be done there.

		Dave

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

* Re: Linux 2.5.70 compile error
  2003-05-28  6:11                   ` Martin J. Bligh
@ 2003-05-28  7:43                     ` William Lee Irwin III
  2003-05-28 15:28                       ` Martin J. Bligh
  0 siblings, 1 reply; 55+ messages in thread
From: William Lee Irwin III @ 2003-05-28  7:43 UTC (permalink / raw)
  To: Martin J. Bligh
  Cc: Dave Jones, Roman Zippel, John Stoffel, DevilKin-LKML, linux-kernel

At some point in the past, my attribution was stripped from:
>> Or better yet, remove all the #ifdefs, finish generalizing the APIC
>> code, and have nothing to configure at all. For 2.7 ...

On Tue, May 27, 2003 at 11:11:20PM -0700, Martin J. Bligh wrote:
> For the "commerical" options like Summit and bigsmp, I think this is an
> option for 2.5 even, given some more testing. And then the wierdo arches
> can be better hidden ;-)

The delimiter between weirdo and non-weirdo arches is wrong IMHO; so
long as the only differences are APIC handling (and that in fact holds
for NUMA-Q and a couple of others that were left out of the generic
bits) a "proper" APIC abstraction should handle it just fine.

One might argue that NUMA-Q is a corner case not worth handling by a
generic APIC layer; it is a corner case, however it far more clearly
shows where generality is needed, in particular because it mixes
clustered hierarchical DFR and logical IPI's with physical DESTMOD in
IO-APIC RTE's. At the moment the general confusions, mis-declarations,
and what appear to be either latent or actual bugs going around
include/asm-i386/mach-*/mach_apic.h point to a need for a consolidated
library of APIC macros and functions accurately conforming to the Intel
specifications. AFAICT there are four and only four or five parameters
that really make a difference:

(1) APIC vs. xAPIC
(2) clustered hierarchical DFR vs. flat DFR
(3) physical DESTMOD vs. logical DESTMOD in IO-APIC RTE's
(4) wakeup via INIT or via NMI
(5) physical IPI's or logical IPI's

So one could easily form destinations by:

physical_destination_t cpumask_to_physical_destination(cpumask_t cpumask)
{
	int cpu, ncpus = cpus_weight(cpumask);

	if (!ncpus) {
		WARN_ON(1);
		if (xapic)
			return XAPIC_PHYSICAL_BROADCAST;
		else
			return SAPIC_PHYSICAL_BROADCAST;
	}

	WARN_ON(ncpus > 1);
	cpu = first_cpu(cpumask);
	if (!xapic && cpu >= 16) {
		WARN_ON(1);
		return SAPIC_PHYSICAL_BROADCAST;
	}

	return (physical_destination_t) { 1UL << cpu };
}

logical_destination_t cpumask_to_logical_destination(cpumask_t cpumask)
{
	unsigned long k, raw_dest = 0UL;

	if (apic_dfr_flat) {
		cpumask_t invalid_mask = cpus_promote(0xFFUL);
		cpus_complement(invalid_mask);
		cpus_and(invalid_mask, invalid_mask, cpumask);
		WARN_ON(!cpus_empty(invalid_mask));
		return (logical_destination_t){ cpus_coerce(cpumask) & 0xFFUL };
	}

	for (k = 0; k < NR_CPUS; ++k) {
		if (!cpu_isset(k, cpumask))
			continue;
		if (raw_dest) {
			unsigned long old_cluster, new_cluster;
			old_cluster = raw_dest >> 4;
			new_cluster = k >> 4;
			if (old_cluster != new_cluster) {
				WARN_ON(1);
				continue;
			}
		}
		raw_dest |= (k & ~0xFUL) | (1UL << (k & 0xf));
	}
	if (!raw_dest) {
		WARN_ON(1);
		return APIC_LOGICAL_BROADCAST;
	}
	return (logical_destination_t) { raw_dest };
}

Destination formation is done in two contexts:
(1) IPI's
(2) IO-APIC RTE's

The higher level of abstraction could easily insulate subarches with:

ipi_destination_t cpumask_to_ipi_destination(cpumask_t cpumask)
{
	switch (APIC_IPI_MODE) {
		case APIC_IPI_MODE_PHYSICAL:
			return cpumask_to_physical_destination(cpumask);
			break;
		case APIC_IPI_MODE_LOGICAL:
			return cpumask_to_logical_destination(cpumask);
			break;
		default:
			BUG();
			return (ipi_destination_t) { 0 };
	}
}

and

rte_destination_t cpumask_to_ipi_destination(cpumask_t cpumask)
{
	switch (IOAPIC_RTE_DESTMOD) {
		case IOAPIC_RTE_DESTMOD_PHYSICAL:
			return cpumask_to_physical_destination(cpumask);
			break;
		case IOAPIC_RTE_DESTMOD_LOGICAL:
			return cpumask_to_logical_destination(cpumask);
			break;
		default:
			BUG();
			return (rte_destination_t) { 0 };
	}
}

with ipi_destination_t typedef'd to physical_destination_t or
logical_destination_t according to the subarch.

CPU wakeup would proceed similarly; just check an operational variable
and either NMI with a logical destination or INIT with a physical
destination, with tabulated BIOS IDT addresses to edit.

And the infamous setup_ioapic_ids_from_mpc() needs a notion of APIC
buses to which IO-APIC's and cpus are connected. It should be look like:

static void __init setup_ioapic_ids_from_mpc(void)
{
	int apic_bus;

	for (apic_bus = 0; apic_bus < MAX_APIC_BUSES; ++apic_bus) {
		unsigned long local_physid_map[BITS_TO_LONGS(XAPIC_PHYSICAL_BROADCAST+1)] = { [0...XAPIC_PHYSICAL_BROADCAST] = 0UL };
		int ioapic, cpu;

		if (!apic_bus_present(apic_bus))
			continue;

		for (cpu = 0; cpu < NR_CPUS; ++cpu) {
			if (!cpu_present(cpu))
				continue;
			if (apic_bus_of_cpu(cpu) != apic_bus)
				continue;

			set_bit(cpu, local_physid_map);
		}

		for (ioapic = 0; ioapic < nr_ioapics; ++ioapic) {
			int ioapic_physid, entry;

			if (apic_bus_of_ioapic(ioapic) != apic_bus)
				continue;

			if (MP_APICID_PHYSICAL)
				ioapic_physid = mp_ioapics[ioapic].mpc_apicid;
			else {
				for (entry = 0; entry < MAX_MPC_ENTRY; ++entry)
					if (!translation_table[entry])
						continue;
					if (translation_table[entry]->mpc_apicid != mp_ioapics[ioapic].mpc_apicid)
						continue;
					if (translation_table[entry]->trans_type == MP_IOAPIC)
						break;

				if (entry >= MAX_MPC_ENTRY)
					panic("IO-APIC %d not listed in"
						" translation table\n", ioapic);
				ioapic_physid = translation_table[entry]->trans_local;
			}

			if (test_bit(ioapic_physid, local_physid_map)) {
				unsigned long free_physids[BITS_TO_LONGS(XAPIC_PHYSICAL_BROADCAST+1)];
				int j, new_physid;
				unsigned long flags;
				struct IO_APIC_reg_00 reg_00;

				for (j = 0; j < ARRAY_SIZE(free_physids); ++j)
					free_physids[j] = ~local_physid_map[j];

				new_physid = find_first_bit(free_physids,
						XAPIC_PHYSICAL_BROADCAST + 1);
				if (!xapic && new_physid >= SAPIC_PHYSICAL_BROADCAST)
					panic("physical APIC ID clash not "
						"resolvable due to physical "
						"APIC ID space exhaustion on "
						"APIC bus %d\n", apic_bus);
				printk("renumbering IO-APIC %d to physical"
					"APIC ID %d from %d\n",
					ioapic, new_physid, ioapic_physid);
				spin_lock_irqsave(&ioapic_lock, flags);
				*(int *)&reg_00 = io_apic_read(ioapic, 0);
				reg_00.ID = new_physid;
				io_apic_write(ioapic, 0, *(int *)&reg_00);
				spin_unlock_irqsave(&ioapic_lock, flags);
				set_bit(new_physid, local_physid_map);
				if (MP_APICID_PHYSICAL)
					mp_ioapics[ioapic].mpc_apicid =
								new_physid;
				else
					translation_table[entry]->trans_local =
								new_physid;
			}
			set_bit(ioapic_physid, local_physid_map);
		}
	}
}

Afterward, APIC-based subarches would just declare their preferences
and the APIC library would dispatch on the operational variables they
declare in mach_apic.h. Shoving the entire thing in a header with
inlines kills off so-called runtime overhead, and the generic subarch
bits would be largely unaltered, and provide a machine vector largely
identical to what it does today. Then, since APIC support is complete,
the detection phases would retarget the APIC driver to the proper
machine vector for the detected machine configuration and work across
a broader variety of systems than it does today.

This is not a pointless exercise: the bogosities I pointed out in the
userspace irqbalancing thread are very real. In particular the APIC vs.
xAPIC oddities for mach-default, though they're not exercised in any
obvious way, are very troubling, and it's unclear whether bigsmp is
peroperly functional as it stands in 2.5.70, since target_cpus()
disallows RTE's targeting clusters > 0 and NO_BALANCE_IRQ is 1. It
vaguely looks like bigsmp cut and paste NUMA-Q APIC code and did the
wrong thing for xAPIC as a result.

Following the spec with respect to destination formation is just not
that far out, people. The above code is just "example code" or whatever
and the BUG() checks are probably overly strict, but the general
notions are basically the rest of what's needed for true APIC genericity.


-- wli

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

* Re: [PATCH] register_ioctl32_conversion symbol exports fix
       [not found]   ` <20030528074701.GA17449@fs.tum.de>
@ 2003-05-28  8:05     ` Andres Salomon
  0 siblings, 0 replies; 55+ messages in thread
From: Andres Salomon @ 2003-05-28  8:05 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: linux-kernel

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

Oops, sorry.  One of these days, I will find an NNTP client that suck..


On Wed, 2003-05-28 at 03:47, Adrian Bunk wrote:
> On Wed, May 28, 2003 at 01:45:33AM -0400, Andres Salomon wrote:
> >...
> > altogether from the arch-specific stuff; so, that's what this patch does
> > (to both {,un}register_ioctl32_conversion).  Please apply (or correct me
> >...
> 
> -ENOPATCH
> 
> cu
> Adrian

[-- Attachment #2: ioctl32.diff --]
[-- Type: text/x-patch, Size: 1949 bytes --]

diff -urN a/arch/ppc64/kernel/ppc_ksyms.c b/arch/ppc64/kernel/ppc_ksyms.c
--- a/arch/ppc64/kernel/ppc_ksyms.c	2003-05-26 21:00:25.000000000 -0400
+++ b/arch/ppc64/kernel/ppc_ksyms.c	2003-05-28 01:15:26.000000000 -0400
@@ -49,8 +49,6 @@
 
 extern int sys_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg);
 extern int do_signal(sigset_t *, struct pt_regs *);
-extern int register_ioctl32_conversion(unsigned int cmd, int (*handler)(unsigned int, unsigned int, unsigned long, struct file *));
-extern int unregister_ioctl32_conversion(unsigned int cmd);
 
 int abs(int);
 
@@ -66,9 +64,6 @@
 EXPORT_SYMBOL(synchronize_irq);
 #endif /* CONFIG_SMP */
 
-EXPORT_SYMBOL(register_ioctl32_conversion);
-EXPORT_SYMBOL(unregister_ioctl32_conversion);
-
 EXPORT_SYMBOL(isa_io_base);
 EXPORT_SYMBOL(pci_io_base);
 
diff -urN a/arch/sparc64/kernel/sparc64_ksyms.c b/arch/sparc64/kernel/sparc64_ksyms.c
--- a/arch/sparc64/kernel/sparc64_ksyms.c	2003-05-26 21:00:46.000000000 -0400
+++ b/arch/sparc64/kernel/sparc64_ksyms.c	2003-05-28 01:14:54.000000000 -0400
@@ -94,8 +94,6 @@
 extern int compat_sys_ioctl(unsigned int fd, unsigned int cmd, u32 arg);
 extern int (*handle_mathemu)(struct pt_regs *, struct fpustate *);
 extern long sparc32_open(const char * filename, int flags, int mode);
-extern int register_ioctl32_conversion(unsigned int cmd, int (*handler)(unsigned int, unsigned int, unsigned long, struct file *));
-extern int unregister_ioctl32_conversion(unsigned int cmd);
 extern int io_remap_page_range(struct vm_area_struct *vma, unsigned long from, unsigned long offset, unsigned long size, pgprot_t prot, int space);
                 
 extern int __ashrdi3(int, int);
@@ -234,10 +232,6 @@
 EXPORT_SYMBOL(pci_dma_supported);
 #endif
 
-/* IOCTL32 emulation hooks. */
-EXPORT_SYMBOL(register_ioctl32_conversion);
-EXPORT_SYMBOL(unregister_ioctl32_conversion);
-
 /* I/O device mmaping on Sparc64. */
 EXPORT_SYMBOL(io_remap_page_range);
 

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

* Re: Linux 2.5.70
  2003-05-27  2:08 Linux 2.5.70 Linus Torvalds
                   ` (4 preceding siblings ...)
  2003-05-28  5:45 ` [PATCH] register_ioctl32_conversion symbol exports fix Andres Salomon
@ 2003-05-28 14:59 ` Paweł Gołaszewski
  5 siblings, 0 replies; 55+ messages in thread
From: Paweł Gołaszewski @ 2003-05-28 14:59 UTC (permalink / raw)
  To: Kernel Mailing List

Finally - I've started to worry if this kernel will be ever released :)

When building framebuffer driver for my new Matrox G400 I get this error:

scripts/fixdep drivers/video/logo/.logo_linux_clut224.o.d drivers/video/logo/logo_linux_clut224.o 'gcc -Wp,-MD,drivers/video/logo/.logo_linux_clut224.o.d -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -Iinclude/asm-i386/mach-default -nostdinc -iwithprefix include    -DKBUILD_BASENAME=logo_linux_clut224 -DKBUILD_MODNAME=logo_linux_clut224 -c -o drivers/video/logo/.tmp_logo_linux_clut224.o drivers/video/logo/logo_linux_clut224.c' > drivers/video/logo/.logo_linux_clut224.o.tmp; rm -f drivers/video/logo/.logo_linux_clut224.o.d; mv -f drivers/video/logo/.logo_linux_clut224.o.tmp drivers/video/logo/.logo_linux_clut224.o.cmd
  LD      drivers/video/logo/built-in.o
  CC      drivers/video/matrox/matroxfb_base.o
In file included from drivers/video/matrox/matroxfb_base.c:105:
drivers/video/matrox/matroxfb_base.h:52: video/fbcon.h: No such file or directory
drivers/video/matrox/matroxfb_base.h:53: video/fbcon-cfb4.h: No such file or directory
drivers/video/matrox/matroxfb_base.h:54: video/fbcon-cfb8.h: No such file or directory
drivers/video/matrox/matroxfb_base.h:55: video/fbcon-cfb16.h: No such file or directory
drivers/video/matrox/matroxfb_base.h:56: video/fbcon-cfb24.h: No such file or directory
drivers/video/matrox/matroxfb_base.h:57: video/fbcon-cfb32.h: No such file or directory
In file included from drivers/video/matrox/matroxfb_base.c:105:
drivers/video/matrox/matroxfb_base.h:341: warning: `struct display' declared inside parameter list
drivers/video/matrox/matroxfb_base.h:341: warning: its scope is only this definition or declaration, which is probably not what you want.
drivers/video/matrox/matroxfb_base.h:342: warning: `struct display' declared inside parameter list
drivers/video/matrox/matroxfb_base.h:558: field `dispsw' has incomplete type
drivers/video/matrox/matroxfb_base.h: In function `mxinfo':
drivers/video/matrox/matroxfb_base.h:633: dereferencing pointer to incomplete 
typedrivers/video/matrox/matroxfb_base.c: At top level:
drivers/video/matrox/matroxfb_base.c:148: warning: braces around scalar initializer
drivers/video/matrox/matroxfb_base.c:148: warning: (near initialization for `vesafb_defined.rotate')
drivers/video/matrox/matroxfb_base.c:148: warning: excess elements in scalar initializer
drivers/video/matrox/matroxfb_base.c:148: warning: (near initialization for `vesafb_defined.rotate')
drivers/video/matrox/matroxfb_base.c:148: warning: excess elements in scalar initializer
drivers/video/matrox/matroxfb_base.c:148: warning: (near initialization for `vesafb_defined.rotate')
drivers/video/matrox/matroxfb_base.c:148: warning: excess elements in scalar initializer
drivers/video/matrox/matroxfb_base.c:148: warning: (near initialization for `vesafb_defined.rotate')
drivers/video/matrox/matroxfb_base.c:148: warning: excess elements in scalar initializer
drivers/video/matrox/matroxfb_base.c:148: warning: (near initialization for `vesafb_defined.rotate')
drivers/video/matrox/matroxfb_base.c:148: warning: excess elements in scalar initializer
drivers/video/matrox/matroxfb_base.c:148: warning: (near initialization for `vesafb_defined.rotate')
drivers/video/matrox/matroxfb_base.c: In function `my_install_cmap':
drivers/video/matrox/matroxfb_base.c:158: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c: In function `matrox_pan_var':
drivers/video/matrox/matroxfb_base.c:186: warning: implicit declaration of function `fontheight'
drivers/video/matrox/matroxfb_base.c:186: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:186: warning: implicit declaration of function `fontwidth'
drivers/video/matrox/matroxfb_base.c:169: warning: `pos' might be used uninitialized in this function
drivers/video/matrox/matroxfb_base.c: In function `matroxfb_remove':
drivers/video/matrox/matroxfb_base.c:238: structure has no member named `disp'
drivers/video/matrox/matroxfb_base.c: In function `matroxfb_pan_display':
drivers/video/matrox/matroxfb_base.c:279: `fb_display' undeclared (first use in this function)
drivers/video/matrox/matroxfb_base.c:279: (Each undeclared identifier is reported only once
drivers/video/matrox/matroxfb_base.c:279: for each function it appears in.)
drivers/video/matrox/matroxfb_base.c: In function `matroxfb_updatevar':
drivers/video/matrox/matroxfb_base.c:303: `fb_display' undeclared (first use in this function)
drivers/video/matrox/matroxfb_base.c: In function `matroxfb_set_var':
drivers/video/matrox/matroxfb_base.c:688: `fb_display' undeclared (first use in this function)
drivers/video/matrox/matroxfb_base.c:690: structure has no member named `disp'
drivers/video/matrox/matroxfb_base.c:700: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:701: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:702: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:703: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:704: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:705: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:706: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:707: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:711: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:721: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:725: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:728: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:729: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:735: structure has no member named `changevar'
drivers/video/matrox/matroxfb_base.c:736: structure has no member named `changevar'
drivers/video/matrox/matroxfb_base.c:802: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:678: warning: `display' might be used uninitialized in this function
drivers/video/matrox/matroxfb_base.c:738: warning: `pos' might be used uninitialized in this function
drivers/video/matrox/matroxfb_base.c: In function `matroxfb_get_cmap':
drivers/video/matrox/matroxfb_base.c:866: structure has no member named `disp'
drivers/video/matrox/matroxfb_base.c:867: `fb_display' undeclared (first use in this function)
drivers/video/matrox/matroxfb_base.c:876: warning: implicit declaration of function `fb_get_cmap'
drivers/video/matrox/matroxfb_base.c:877: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:878: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:880: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c: In function `matroxfb_set_cmap':
drivers/video/matrox/matroxfb_base.c:890: structure has no member named `disp'
drivers/video/matrox/matroxfb_base.c:890: `fb_display' undeclared (first use in this function)
drivers/video/matrox/matroxfb_base.c:899: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:900: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:903: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:910: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c: In function `matroxfb_ioctl':
drivers/video/matrox/matroxfb_base.c:1009: structure has no member named `switch_con'
drivers/video/matrox/matroxfb_base.c: At top level:
drivers/video/matrox/matroxfb_base.c:1188: unknown field `fb_set_var' specified in initializer
drivers/video/matrox/matroxfb_base.c:1188: warning: initialization from incompatible pointer type
drivers/video/matrox/matroxfb_base.c:1189: unknown field `fb_get_cmap' specified in initializer
drivers/video/matrox/matroxfb_base.c:1189: warning: initialization from incompatible pointer type
drivers/video/matrox/matroxfb_base.c:1190: unknown field `fb_set_cmap' specified in initializer
drivers/video/matrox/matroxfb_base.c:1190: warning: initialization from incompatible pointer type
drivers/video/matrox/matroxfb_base.c:1192: warning: initialization from incompatible pointer type
drivers/video/matrox/matroxfb_base.c:1194: warning: initialization from incompatible pointer type
drivers/video/matrox/matroxfb_base.c: In function `matroxfb_switch':
drivers/video/matrox/matroxfb_base.c:1207: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:1222: structure has no member named `disp'
drivers/video/matrox/matroxfb_base.c:1224: `fb_display' undeclared (first use in this function)
drivers/video/matrox/matroxfb_base.c:1226: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:1235: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:1200: warning: `cmap' might be used uninitialized in this function
drivers/video/matrox/matroxfb_base.c:1201: warning: `p' might be used uninitialized in this function
drivers/video/matrox/matroxfb_base.c: In function `initMatrox2':
drivers/video/matrox/matroxfb_base.c:1741: structure has no member named `fontname'
drivers/video/matrox/matroxfb_base.c:1742: structure has no member named `fontname'
drivers/video/matrox/matroxfb_base.c:1753: structure has no member named `modename'
drivers/video/matrox/matroxfb_base.c:1754: structure has no member named `changevar'
drivers/video/matrox/matroxfb_base.c:1756: structure has no member named `disp'
drivers/video/matrox/matroxfb_base.c:1757: structure has no member named `switch_con'
drivers/video/matrox/matroxfb_base.c:1758: structure has no member named `updatevar'
drivers/video/matrox/matroxfb_base.c:1874: structure has no member named `modename'
drivers/video/matrox/matroxfb_base.c: In function `matroxfb_probe':
drivers/video/matrox/matroxfb_base.c:2015: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:2027: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:2027: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:2027: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:2027: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:2027: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:2027: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:2034: structure has no member named `fontname'
drivers/video/matrox/matroxfb_base.c:2034: structure has no member named `fontname'
drivers/video/matrox/matroxfb_base.c:2034: structure has no member named `fontname'
drivers/video/matrox/matroxfb_base.c:2034: structure has no member named `fontname'
drivers/video/matrox/matroxfb_base.c:2034: structure has no member named `fontname'
make[3]: *** [drivers/video/matrox/matroxfb_base.o] Error 1
make[2]: *** [drivers/video/matrox] Error 2
make[1]: *** [drivers/video] Error 2
make: *** [drivers] Error 2
Command exited with non-zero status 2



-- 
pozdr.  Pawe? Go?aszewski 
---------------------------------
worth to see: http://www.againsttcpa.com/
CPU not found - software emulation...

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

* Re: Linux 2.5.70 compile error
  2003-05-28  7:43                     ` William Lee Irwin III
@ 2003-05-28 15:28                       ` Martin J. Bligh
  2003-05-29  1:14                         ` William Lee Irwin III
  0 siblings, 1 reply; 55+ messages in thread
From: Martin J. Bligh @ 2003-05-28 15:28 UTC (permalink / raw)
  To: William Lee Irwin III
  Cc: Dave Jones, Roman Zippel, John Stoffel, DevilKin-LKML, linux-kernel

> (1) APIC vs. xAPIC
> (2) clustered hierarchical DFR vs. flat DFR
> (3) physical DESTMOD vs. logical DESTMOD in IO-APIC RTE's
> (4) wakeup via INIT or via NMI
> (5) physical IPI's or logical IPI's
> 
> So one could easily form destinations by:

Yes. It's fixable, and I think that's a good project for 2.7, but I really
don't think that level of change is justified at the moment. Testing this
stuff is a pain in the ass, it's a lot of work to do properly and carefully.
And what does that change buy us in reality? Not a lot. 

I agree it would be nice to do ... just not the focus during a 2.6 
stabilisation effort, when we have so many other more important things to
work on, that would have real impact.

M.


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

* Re: Linux 2.5.70
  2003-05-27 17:26   ` Linus Torvalds
  2003-05-27 16:48     ` Alan Cox
  2003-05-27 18:09     ` Ricky Beam
@ 2003-05-28 15:58     ` Bill Davidsen
  2003-05-28 16:14       ` Linus Torvalds
  2 siblings, 1 reply; 55+ messages in thread
From: Bill Davidsen @ 2003-05-28 15:58 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Ricky Beam, Kernel Mailing List

On Tue, 27 May 2003, Linus Torvalds wrote:

> 
> On Tue, 27 May 2003, Ricky Beam wrote:
> > 
> > Count up the number of drivers that haven't been updated to the current
> > PCI, hotplug, and modules interfaces.
> 
> Tough. If people don't use them, they don't get supported. It's that easy.

Just the other day you posted strong opposition to breaking existing
binaries, how does that map with breaking existing hardware?
> 
> The thing is, these things won't change before 2.6 (or at least a 
> pre-2.6). When 2.6.0 comes out, and somebody notices that they haven't 
> bothered to try the 2.5.x series, _then_ maybe some of those odd-ball 
> drivers get fixed.
> 
> Or not. Some of them may be literally due for retirement, with users just 
> running an old kernel on old hardware.
> 
> Btw, this is nothing new. It has _always_ been the case that a lot of 
> people didn't use the latest stable kernel until it was released, and then 
> they complained because the drivers they used weren't up to spec.
> 
> 			Linus

That's clearly true, but part of the reason is that some drivers just
don't compile, so people assume it's a work in progress. And when problems
are reported they sometimes don't get fixed even when there is a
maintainer listed for a driver. Hopefully vendors will pick up the slack
for things like that and the power management issues.

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


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

* Re: Linux 2.5.70
  2003-05-27 18:09     ` Ricky Beam
                         ` (2 preceding siblings ...)
  2003-05-27 19:18       ` Adrian Bunk
@ 2003-05-28 16:08       ` Bill Davidsen
  3 siblings, 0 replies; 55+ messages in thread
From: Bill Davidsen @ 2003-05-28 16:08 UTC (permalink / raw)
  To: Ricky Beam; +Cc: Kernel Mailing List

On Tue, 27 May 2003, Ricky Beam wrote:

> On Tue, 27 May 2003, Linus Torvalds wrote:
> >On Tue, 27 May 2003, Ricky Beam wrote:
> >>
> >> Count up the number of drivers that haven't been updated to the current
> >> PCI, hotplug, and modules interfaces.
> >
> >Tough. If people don't use them, they don't get supported. It's that easy.
> ...
> 
> Allow me to clarify... I don't mind drivers not working.  I *do* mind
> drivers emitting hundreds of warnings and errors because dozens of things
> were changed and no one cared to update everything they broke.  In some
> cases, fixing things may be simple (eg. someone removed or renamed a field
> in a struct somewhere) and in others years of work my be required (eg.
> the new module interface.)
> 
> In my opinion (as it was in the long long ago), everything in a "stable"
> release should at least compile cleanly -- "working" comes later after
> users have been conned into using it.

See the stats posted to lkml from time to time on errors and warnings. The
2.4 stable kernels don't compile cleanly, with some combinations of config
options they may not compile at all. The ones which compile and work, even
with all manner of warnings, are a good place to start doing some
housekeeping and sending it back to the maintainer.

Maintainers vary on their desire to push cosmetic fixes into working
code, even when they are correct.

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


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

* Re: Linux 2.5.70
  2003-05-28 15:58     ` Bill Davidsen
@ 2003-05-28 16:14       ` Linus Torvalds
  2003-05-28 19:22         ` ismail (cartman) donmez
  2003-05-28 22:40         ` Bill Davidsen
  0 siblings, 2 replies; 55+ messages in thread
From: Linus Torvalds @ 2003-05-28 16:14 UTC (permalink / raw)
  To: Bill Davidsen; +Cc: Ricky Beam, Kernel Mailing List


On Wed, 28 May 2003, Bill Davidsen wrote:
> 
> Just the other day you posted strong opposition to breaking existing
> binaries, how does that map with breaking existing hardware?

One fundamental difference is that I cannot fix it without people who
_have_ the hardware caring. So if they don't care, I don't care. It's that
easy. If you want to have your hardware supported, you need to help
support it.

Another difference is that it's better to not work at all, than to work
incorrectly. So if your kernel doesn't boot or can't use your random piece
of hardware, you just use an old kernel. But if everything looks normal,
but some binary breaks in strange ways, that's _bad_.

The latter reason is, btw, why we don't paper over the build failures like 
some people suggested. If it hasn't been updated to the new interfaces, it 
should preferably not even build: which is a big reason why we try to 
rename interfaces when they change, exactly so that you don't get a subtly 
broken build.

		Linus


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

* Re: Linux 2.5.70
  2003-05-27 21:42 ` John Cherry
@ 2003-05-28 17:55   ` John Cherry
  0 siblings, 0 replies; 55+ messages in thread
From: John Cherry @ 2003-05-28 17:55 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Kernel Mailing List

Sorry.  There was a translation error in the last batch of numbers I
sent out.  We actually went from 1567 warnings in a full allmodconfig
build to 1366 warning (down 201 warnings!).



          bzImage       bzImage        modules
        (defconfig)  (allmodconfig) (allmodconfig)

2.5.70  7 warnings    10 warnings   1366 warnings
        0 errors       0 errors       57 errors

2.5.69  7 warnings    11 warnings   1567 warnings
        0 errors       0 errors       57 errors

2.5.68  7 warnings    11 warnings   1975 warnings
        0 errors       6 errors       60 errors

2.5.67  8 warnings    12 warnings   2136 warnings
        0 errors       6 errors       89 errros

John


On Tue, 2003-05-27 at 14:42, John Cherry wrote:
> ompile statistics: 2.5.70
> Compiler: gcc 3.2.2
> Script: http://www.osdl.org/archive/cherry/stability/compregress.sh
> 
>           bzImage       bzImage        modules
>         (defconfig)  (allmodconfig) (allmodconfig)
> 
> 2.5.70  7 warnings    10 warnings   1366 warnings
>         0 errors       0 errors       57 errors
> 
> 2.5.69  7 warnings    11 warnings   1366 warnings
>         0 errors       0 errors       57 errors
> 
> 2.5.68  7 warnings    11 warnings   1975 warnings
>         0 errors       6 errors       60 errors
> 
> 2.5.67  8 warnings    12 warnings   2136 warnings
>         0 errors       6 errors       89 errros
> 
> 
> Compile statistics have been for kernel releases from 2.5.46 to 2.5.70
> at: www.osdl.org/archive/cherry/stability
> 
> Failure summary:
> 
>    drivers/block: 2 warnings, 1 errors
>    drivers/char: 237 warnings, 4 errors
>    drivers/isdn: 237 warnings, 8 errors
>    drivers/media: 102 warnings, 5 errors
>    drivers/mtd: 31 warnings, 1 errors
>    drivers/net: 336 warnings, 6 errors
>    drivers/scsi/aic7xxx: 0 warnings, 1 errors
>    drivers/video/i810: 3 warnings, 4 errors
>    drivers/video/matrox: 3 warnings, 10 errors
>    drivers/video: 81 warnings, 17 errors
>    sound/oss: 49 warnings, 3 errors
>    sound: 5 warnings, 3 errors
> 
> 
> Warning summary:
> 
> 
>    drivers/atm: 36 warnings, 0 errors
>    drivers/cdrom: 25 warnings, 0 errors
>    drivers/hotplug: 1 warnings, 0 errors
>    drivers/i2c: 3 warnings, 0 errors
>    drivers/ide: 32 warnings, 0 errors
>    drivers/md: 2 warnings, 0 errors
>    drivers/message: 1 warnings, 0 errors
>    drivers/pcmcia: 3 warnings, 0 errors
>    drivers/scsi/aacraid: 1 warnings, 0 errors
>    drivers/scsi/pcmcia: 4 warnings, 0 errors
>    drivers/scsi/sym53c8xx_2: 1 warnings, 0 errors
>    drivers/serial: 1 warnings, 0 errors
>    drivers/telephony: 10 warnings, 0 errors
>    drivers/usb: 13 warnings, 0 errors
>    drivers/video/aty: 4 warnings, 0 errors
>    drivers/video/sis: 3 warnings, 0 errors
>    fs/afs: 1 warnings, 0 errors
>    fs/cifs: 1 warnings, 0 errors
>    fs/intermezzo: 1 warnings, 0 errors
>    fs/lockd: 4 warnings, 0 errors
>    fs/nfsd: 2 warnings, 0 errors
>    fs/smbfs: 2 warnings, 0 errors
>    net: 30 warnings, 0 errors
>    security: 2 warnings, 0 errors
>    sound/isa: 3 warnings, 0 errors
>    sound/pci: 1 warnings, 0 errors
>    sound/usb: 2 warnings, 0 errors
> 
> 
> 
> Other stability-related links:
>    OSDL Stability page:
>        http://osdl.org/projects/26lnxstblztn/results/
>    Nightly linux-2.5 bk build:
>        www.osdl.org/archive/cherry/stability/linus-tree/running.txt
>    2.5 porting items:
>        www.osdl.org/archive/cherry/stability/linus-tree/port_items.txt
>    2.5 porting items history:
>        www.osdl.org/archive/cherry/stability/linus-tree/port_history.txt
> 
> John
> 
> 
> 
> -
> 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] 55+ messages in thread

* Re: Linux 2.5.70
  2003-05-28 16:14       ` Linus Torvalds
@ 2003-05-28 19:22         ` ismail (cartman) donmez
  2003-05-29 11:14           ` Dave Jones
  2003-05-28 22:40         ` Bill Davidsen
  1 sibling, 1 reply; 55+ messages in thread
From: ismail (cartman) donmez @ 2003-05-28 19:22 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Kernel Mailing List

On Wednesday 28 May 2003 19:14, Linus Torvalds wrote:
> On Wed, 28 May 2003, Bill Davidsen wrote:
> > Just the other day you posted strong opposition to breaking existing
> > binaries, how does that map with breaking existing hardware?
>
> One fundamental difference is that I cannot fix it without people who
> _have_ the hardware caring. So if they don't care, I don't care. It's that
> easy. If you want to have your hardware supported, you need to help
> support it.

Quite true. But there are bugs at kernel bugzilla which

1- People care about it being fixed
2- Tests beta kernels to see if its fixed
3- Reports success/failures

But still these bugs are unresolved. I do not say/mean kernel hackers do not 
care them or something like that but it would be better to get these kind of 
bugs ( with user base who tests them ) fixed before pre-2.6 releases.

Regards,
/ismail

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

* Re: Linux 2.5.70 compile error
  2003-05-27 21:59               ` Martin J. Bligh
  2003-05-27 23:40                 ` Dave Jones
  2003-05-28  3:34                 ` William Lee Irwin III
@ 2003-05-28 22:08                 ` Bill Davidsen
  2003-05-29  0:36                   ` Martin J. Bligh
  2 siblings, 1 reply; 55+ messages in thread
From: Bill Davidsen @ 2003-05-28 22:08 UTC (permalink / raw)
  To: Martin J. Bligh; +Cc: Linux Kernel Mailing List

On Tue, 27 May 2003, Martin J. Bligh wrote:

> >  > > What the hell am I supposed to enter here?  This is just friggin ugly
> >  > > and un-readable.  It should be cleaned up.
> >  > I agree and I already fixed this here, so with the next update this will 
> >  > look like this:
> >  > 
> >  > Subarchitecture Type
> >  > > 1. PC-compatible (X86_PC)
> >  >   2. Voyager (NCR) (X86_VOYAGER)
> >  >   3. NUMAQ (IBM/Sequent) (X86_NUMAQ)
> >  >   4. Summit/EXA (IBM x440) (X86_SUMMIT)
> >  >   5. Support for other sub-arch SMP systems with more than 8 CPUs (X86_BIGSMP)
> >  >   6. SGI 320/540 (Visual Workstation) (X86_VISWS)
> >  >   7. Generic architecture (Summit, bigsmp, default) (X86_GENERICARCH) (NEW)
> >  > choice[1-7]: 
> >  > 
> >  > This has other advantages too, one can see now which options were newly 
> >  > added and the individual help texts are accessible.
> > 
> > Given that 99% of users will be choosing option 1, it might be a
> > good thing to have the remaining options only shown if a
> > CONFIG_X86_SUBARCHS=y and have things default to option 1 if =n.
> 
> Please, not more layered config options! That just makes people who
> want to enable the x440 or other alternative platform require fair
> amounts of psychic power (maybe this can be fixed with a big fat help
> message, but so can the current method).

You have one good idea here, leaving the output unreadable is not it. I
was going to suggest a readable menu but someone beat me to it, it's the
obvious choice for this much stuuf, rather than one (usually folded) line.
>
> If you're going hide the other options away so much, then the default
> should be the generic arch, IMHO.

Not *that* is the good idea! A nice multiple choice menu with a note to
leave alone unless you have a clue is the right way to do it, but the
default should be what's most likely to work.

You will not get people to leave it alone by making it unreadable, you
will just confust the shit out of them by letting them see such detail if
they don't go looking for it. IMHO of course.

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


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

* Re: Linux 2.5.70
  2003-05-28 16:14       ` Linus Torvalds
  2003-05-28 19:22         ` ismail (cartman) donmez
@ 2003-05-28 22:40         ` Bill Davidsen
  1 sibling, 0 replies; 55+ messages in thread
From: Bill Davidsen @ 2003-05-28 22:40 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Ricky Beam, Kernel Mailing List

On Wed, 28 May 2003, Linus Torvalds wrote:

> 
> On Wed, 28 May 2003, Bill Davidsen wrote:
> > 
> > Just the other day you posted strong opposition to breaking existing
> > binaries, how does that map with breaking existing hardware?
> 
> One fundamental difference is that I cannot fix it without people who
> _have_ the hardware caring. So if they don't care, I don't care. It's that
> easy. If you want to have your hardware supported, you need to help
> support it.

That's the case now, isn't it? unless the person with the non-working
hardware is willing and able to become the maintainer a lot of drivers
don't seem to get fixed. Unfortunately that the people with the old
hardware usually aren't developers.
> 
> Another difference is that it's better to not work at all, than to work
> incorrectly. So if your kernel doesn't boot or can't use your random piece
> of hardware, you just use an old kernel. But if everything looks normal,
> but some binary breaks in strange ways, that's _bad_.

Totally agree.
> 
> The latter reason is, btw, why we don't paper over the build failures like 
> some people suggested. If it hasn't been updated to the new interfaces, it 
> should preferably not even build: which is a big reason why we try to 
> rename interfaces when they change, exactly so that you don't get a subtly 
> broken build.

I don't think anyone suggested that, but there are a fair number of
drivers which could be fixed in minutes by someone who understands the new
interface. Replacing cli is easy, knowing what you replace it with is
something else again. There are new locks, per-cpu stuff added, lockless
methods... to do this right you have to do it often, and few users can do
more than give an error report which allows the problem to be reproduced.

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


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

* Re: Linux 2.5.70 compile error
  2003-05-28 22:08                 ` Bill Davidsen
@ 2003-05-29  0:36                   ` Martin J. Bligh
  0 siblings, 0 replies; 55+ messages in thread
From: Martin J. Bligh @ 2003-05-29  0:36 UTC (permalink / raw)
  To: Bill Davidsen; +Cc: Linux Kernel Mailing List

> You will not get people to leave it alone by making it unreadable, you
> will just confust the shit out of them by letting them see such detail if
> they don't go looking for it. IMHO of course.

Oh, I wasn't disputing that should be fixed. I always use menuconfig,
or pipe something to oldconfig, so I don't see it personally ... but
that seemed to be under no debate - Roman already said he'd fix that;
it's obviously a bug.

M.


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

* Re: Linux 2.5.70 compile error
  2003-05-28 15:28                       ` Martin J. Bligh
@ 2003-05-29  1:14                         ` William Lee Irwin III
  0 siblings, 0 replies; 55+ messages in thread
From: William Lee Irwin III @ 2003-05-29  1:14 UTC (permalink / raw)
  To: Martin J. Bligh
  Cc: Dave Jones, Roman Zippel, John Stoffel, DevilKin-LKML, linux-kernel

At some point in the past, my attribution was stripped from:
>> (1) APIC vs. xAPIC
>> (2) clustered hierarchical DFR vs. flat DFR
>> (3) physical DESTMOD vs. logical DESTMOD in IO-APIC RTE's
>> (4) wakeup via INIT or via NMI
>> (5) physical IPI's or logical IPI's
>> So one could easily form destinations by:

On Wed, May 28, 2003 at 08:28:09AM -0700, Martin J. Bligh wrote:
> Yes. It's fixable, and I think that's a good project for 2.7, but I really
> don't think that level of change is justified at the moment. Testing this
> stuff is a pain in the ass, it's a lot of work to do properly and carefully.
> And what does that change buy us in reality? Not a lot. 
> I agree it would be nice to do ... just not the focus during a 2.6 
> stabilisation effort, when we have so many other more important things to
> work on, that would have real impact.

Yes, it's 2.7 material.


-- wli

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

* Re: Linux 2.5.70
  2003-05-29 11:14           ` Dave Jones
@ 2003-05-29 11:14             ` ismail (cartman) donmez
  0 siblings, 0 replies; 55+ messages in thread
From: ismail (cartman) donmez @ 2003-05-29 11:14 UTC (permalink / raw)
  To: Dave Jones; +Cc: Linus Torvalds, Kernel Mailing List

On Thursday 29 May 2003 14:14, Dave Jones wrote:
> Quite a lot of the 'xxx driver does not compile' bugs in bugzilla
> may actually have been filed by people just doing coverage testing
> to see what actually compiles and what doesn't.
> This does unfortunatly make it harder to see at first glance which
> drivers are actually still being used by users. The fact that quite
> a few of them have no follow-ups does suggest however that no-one who
> actually has the hardware cares enough to keep pushing to get things
> fixed.  Moving a bunch of these under a CONFIG_BROKEN could be a useful
> thing to seperate the wheat from the chaff.

I was talking about bugs where user does provide valuable feedback not just 
this/that does not compile but more info,debugging,testing etc.

Regards,
/ismail

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

* Re: Linux 2.5.70
  2003-05-28 19:22         ` ismail (cartman) donmez
@ 2003-05-29 11:14           ` Dave Jones
  2003-05-29 11:14             ` ismail (cartman) donmez
  0 siblings, 1 reply; 55+ messages in thread
From: Dave Jones @ 2003-05-29 11:14 UTC (permalink / raw)
  To: ismail (cartman) donmez; +Cc: Linus Torvalds, Kernel Mailing List

On Wed, May 28, 2003 at 10:22:42PM +0300, ismail (cartman) donmez wrote:

 > Quite true. But there are bugs at kernel bugzilla which
 > 
 > 1- People care about it being fixed
 > 2- Tests beta kernels to see if its fixed
 > 3- Reports success/failures
 > 
 > But still these bugs are unresolved. I do not say/mean kernel hackers do not 
 > care them or something like that but it would be better to get these kind of 
 > bugs ( with user base who tests them ) fixed before pre-2.6 releases.

Quite a lot of the 'xxx driver does not compile' bugs in bugzilla
may actually have been filed by people just doing coverage testing
to see what actually compiles and what doesn't.
This does unfortunatly make it harder to see at first glance which
drivers are actually still being used by users. The fact that quite
a few of them have no follow-ups does suggest however that no-one who
actually has the hardware cares enough to keep pushing to get things
fixed.  Moving a bunch of these under a CONFIG_BROKEN could be a useful
thing to seperate the wheat from the chaff.

		Dave


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

end of thread, other threads:[~2003-05-29 11:01 UTC | newest]

Thread overview: 55+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-27  2:08 Linux 2.5.70 Linus Torvalds
2003-05-27  2:45 ` Linux 2.5.70 (Compiler warnings) Udo A. Steinberg
2003-05-27  3:09   ` YOSHIFUJI Hideaki / 吉藤英明
2003-05-27  7:10     ` David S. Miller
2003-05-27  8:48 ` Linux 2.5.70 compile error DevilKin
2003-05-27 13:05   ` William Lee Irwin III
2003-05-27 15:29     ` DevilKin-LKML
2003-05-27 15:36       ` William Lee Irwin III
2003-05-27 15:48         ` John Stoffel
2003-05-27 15:52           ` William Lee Irwin III
2003-05-27 16:35             ` John Stoffel
2003-05-27 16:43               ` William Lee Irwin III
2003-05-27 17:50                 ` John Stoffel
2003-05-27 17:56                   ` William Lee Irwin III
2003-05-27 21:56                   ` Martin J. Bligh
2003-05-27 18:19           ` Roman Zippel
2003-05-27 18:40             ` Dave Jones
2003-05-27 18:50               ` William Lee Irwin III
2003-05-27 21:59               ` Martin J. Bligh
2003-05-27 23:40                 ` Dave Jones
2003-05-28  3:20                   ` Martin J. Bligh
2003-05-28  3:34                 ` William Lee Irwin III
2003-05-28  6:11                   ` Martin J. Bligh
2003-05-28  7:43                     ` William Lee Irwin III
2003-05-28 15:28                       ` Martin J. Bligh
2003-05-29  1:14                         ` William Lee Irwin III
2003-05-28  6:52                   ` Dave Jones
2003-05-28 22:08                 ` Bill Davidsen
2003-05-29  0:36                   ` Martin J. Bligh
2003-05-27 19:46             ` John Stoffel
2003-05-27 15:38       ` Sean Neakums
2003-05-27 15:52         ` Martin J. Bligh
2003-05-27 16:58 ` Linux 2.5.70 Ricky Beam
2003-05-27 17:26   ` Linus Torvalds
2003-05-27 16:48     ` Alan Cox
2003-05-27 17:53       ` Linus Torvalds
2003-05-27 21:15         ` Hans Reiser
2003-05-27 18:09     ` Ricky Beam
2003-05-27 18:22       ` Jeff Garzik
2003-05-27 18:31       ` Robert Love
2003-05-27 19:18       ` Adrian Bunk
2003-05-28 16:08       ` Bill Davidsen
2003-05-28 15:58     ` Bill Davidsen
2003-05-28 16:14       ` Linus Torvalds
2003-05-28 19:22         ` ismail (cartman) donmez
2003-05-29 11:14           ` Dave Jones
2003-05-29 11:14             ` ismail (cartman) donmez
2003-05-28 22:40         ` Bill Davidsen
2003-05-27 21:06   ` Andreas Boman
2003-05-28  2:30   ` Daniel Phillips
2003-05-27 21:42 ` John Cherry
2003-05-28 17:55   ` John Cherry
2003-05-28  5:45 ` [PATCH] register_ioctl32_conversion symbol exports fix Andres Salomon
     [not found]   ` <20030528074701.GA17449@fs.tum.de>
2003-05-28  8:05     ` Andres Salomon
2003-05-28 14:59 ` Linux 2.5.70 Paweł Gołaszewski

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).