Linux: 2.5.46 released

Submitted by schneelocke
on November 4, 2002 - 8:33pm

Version 2.5.46 of the 2.5 (development) branch of the Linux kernel has just been released by Linus Torvalds. This release, which is another step towards the final 2.6 kernel expected by June 2003 [story], features a number of exciting new features; apart from the already-mentioned extended attributes and ACLs for ext2 and ext3, hugetlbfs, v4l2 Video for Linux layer and the Orlov block allocator for ext2 [story], this release also features ACLs for JFS, initramfs, the first driverfs patches, usage of the Orlov block allocator for ext3, a ucLinux merge (support for MMU-less architectures) and, as usual, tons of fixes, updates and minor improvements, including updates for the ARM, m68k and ia64 architectures. Read on for Linus' full announcement.

From:     Linus Torvalds 
To:       linux-kernel
Subject:  Linux v2.5.46
Date:     2002-11-04 23:13:04

Ok, our dear master.kernel.org seems to be back from the dead, which means 
that I can punish it some more and upload stuff to it again. 

2.5.46 merges some more stuff (yeah, I still have stuff in my mailbox, but
I'm calmer now that I don't forsee any more huge issues), and is pretty
much all over the map. Merges with Alan, Al and Andrew, and m68k stuff
from Geert. Sysfs from Pat, and ext2/3 updates from Ted.

		Linus

----

Summary of changes from v2.5.45 to v2.5.46
============================================

Adam Radford :
  o 3ware driver update for 2.5.46, sync cache, 64-bit, etc

Alan Cox :
  o Alpha escaped pcibios
  o kill debug printk we dont need now
  o kill pcibios in m6k8
  o kill pcibios in m68k pci code
  o 32/64bit device mapper ioctl maps for mips64
  o kill pcibios in ppc32
  o device mapper ioctls for ppc64
  o device mapper 64/32bit ioctl maps for S/390x
  o fix warnings
  o add voyager specific extra key map
  o use longer delays on 3c509
  o warning fixes
  o kill stupid search and destroy error
  o without this tulip doesn't build non modular
  o move de4x5 to new pci api
  o fix filters types on winbond 840
  o remove more tqueue.h
  o eata update from maintainer
  o restore inia100.h abort/reset
  o restore missing error handlers for ncr53c8xx
  o ditto error handling for qla1280
  o ditto for sym53c8xx
  o update the u14-34f driver to maintainer updates
  o make afs build with gcc 2.9x
  o add includes for voyager interrupt chip
  o header update to match m68k pci change
  o update MAINTAINERS
  o make rxrpc build with gcc 2.x
  o some trident needs longer delays to power up codecs
  o fix i810 printk error
  o MAINTAINERS entries for UcLinux platforms
  o UCLinux generic memory mapped MTD driver
  o UCLINUX ethernet driver for 68360 on board ethernet
  o Kconfig and makfile goo for new net drivers
  o UCLINUX ethernet driver for Coldfire onboard 100Mbit ethernet
  o arch specific files for MMUless NEC v850 port
  o add machine ident for the V850 from NEC
  o UCLINUX "flat" binary loader
  o UCLINUX (forgot one) - header file for binfmt_flat
  o 2.5.45 UCLinux merge M680x0 mmuless arch and include/asm

Alexander Viro :
  o fix 2.5.45 initrd breakage
  o tape_name() in osst.c

  o tape_name() in st.c
  o file->private_data in st.c and osst.c
  o osst template
  o st template
  o sr template
  o sd template
  o sg template
  o scsi_get_request_dev() cleanup
  o >rq_dev in aacraid
  o generic uses of ->rq_dev
  o uses of ->rq_dev in printks
  o remaining uses of ->rq_dev
  o death of ->rq_dev

Andi Kleen :
  o Make x86-64 compile

Andrew Morton :
  o hugetlbpages: factor out some code for hugetlbfs
  o Move hugetlb declarations into their own header
  o hugetlb fixes andhugetlb fixes and cleanups cleanups
  o fix hugetlb thinko
  o hugetlbfs file system
  o hugetlbfs backing for SYSV shared memory
  o Orlov block allocator for ext2
  o speedup heuristic for get_unmapped_area
  o uninline some things in mm/*.c
  o flush_dcache_page in get_user_pages()
  o lru_add_active(): for starting pages on the active list
  o start anon pages on the active list (properly this time)
  o empty the deferred lru-addition buffers in swapin_readahead
  o exempt swapcahe pages from "use once" handling
  o strip pagecache from to-be-reaped inodes
  o sys_remap_file_pages
  o tmpfs support for remap_file_pages
  o use RCU for IPC locking
  o uninlining in ipc/*
  o make kernel_stat use per-cpu infrastructure
  o additional arch support for per-cpu kernel_stat
  o direct-io build fix
  o use bd_claim in the raw driver
  o faster wakeups in the pipe code
  o improved space efficiency in dcache
  o disable PF_MEMALLOC for interrupt allocations
  o ext3 build fix
  o page accounting atomicity fix
  o Update/Create core files for DriverFS Topology
  o i386 driverfs Topology
  o NUMA meminfo for driverfs Topology
  o create memblk_online_map
  o create node_online_map
  o driverfs topology cleanup

Andy Grover :
  o ACPI
  o ACPI: Ensure we don't try to sleep when we shouldn't
  o ACPI: Interpreter update to (20021101)

Arnaldo Carvalho de Melo :
  o isapnp: fix typo in isapnp_proc_done when CONFIG_PROC_FS is not set

Christoph Hellwig :
  o add CONFIG_MMU and CONFIG_SWAP
  o make swap code conditional
  o filemap.c bits for uClinux
  o page_alloc.c uClinux bits

Daniel Jacobowitz :
  o Factor out common ptrace code and PTRACE_SETOPTIONS Support
    PTRACE_O_TRACESYSGOOD on all platforms
  o Add CLONE_UNTRACED to the flags forced by kernel_thread
  o Add new ptrace event tracing mechanism
  o Define CLONE_UNTRACED in more architecture files and correct PA
    typo

Dave Jones :
  o Clean up capabilities printing
  o max_cpus overflow
  o Double x86 initialise fix

Dave Kleikamp :
  o JFS: forced metadata pages were not being flushed to disk
  o JFS: add posix acls

David Howells :
  o AFS compile breakage

David Mosberger :
  o ia64: Hook up sys_lookup_dcookie()
  o ia64: Sync up with 2.5.45
  o ia64: Update defconfig

David S. Miller :
  o Fix partitions build failure

Davide Libenzi :
  o epoll update r3

Dominik Brodowski :
  o cpufreq: update HyperThreading support in p4-clockmod.c driver
  o cpufreq: /proc/sys/cpu and /proc/cpufreq can be used simultaneously

Erich Focht :
  o ia64: 2.5.44 NUMA fixups

Geert Uytterhoeven :
  o C99 designated initializers for include/asm-m68k/thread_info.h
  o M68k speaker driver can be a modular
  o m68k IP checksum fix
  o M68k epoll
  o Fix dyslexia in Amiga keyboard driver
  o M68k misc compile fixes
  o M68k dump_stack() updates
  o M68k genrtc updates
  o vesafb 6x11 font fix
  o M68k IDE lock fixes
  o HP9000/300 I/O access fixes
  o M68k INIT_SIGNALS() update
  o Enable console on m68k
  o M68k: Fix missing/superfluous includes
  o Convert m68k cache macros to inline functions
  o M68k ISA DMA update
  o M68k: fix init_task section
  o M68k irq updates
  o m68k asm/kmap_types.h
  o M68k *_mksound() prototypes
  o M68k local_irq*() updates
  o M68k linker file updates
  o M68k build fixes
  o m68k do_fork() update
  o Atari nvram fix
  o Export m68k_memoffset
  o M68k asm/percpu.h
  o Allow to disable macfb
  o Q40/Q60 RTC update
  o M68k input drivers cleanup
  o M68k needs WANT_PAGE_VIRTUAL
  o M68k iomap cleanup
  o M68k virt/phys fallback removal
  o mac8390 Ethernet
  o IDE: kill warning
  o Amiga serial: static function
  o contact update
  o Sun-3 ioremap()
  o Sun-3 doc updates
  o Mac/m68k spelling
  o M68k: optimize stacked irq check
  o M68k TIF_SYSCALL_TRACE
  o Sun-3 SCSI updates
  o Z2ram: Add missing closing brace
  o Sun-3 vectored interrupts
  o Sun-3/3x updates
  o Zorro ID update
  o Fix rwsemtrace() message
  o m68k xtime update
  o Sun-3 VME support
  o Zorro loff_t
  o Sun-3 DVMA debugging
  o m68k unused cruft removal

Gerd Knorr :
  o videobuf update
  o add v4l2 api
  o tv tuner driver update
  o bttv documentation update
  o bttv update
  o new v4l2 driver: saa7134

Ivan Kokshaysky :
  o alpha ISA dma and MAX_DMA_ADDRESS
  o more alpha build fixes
  o alpha: common ev6/ev7 machine check handler

Jeff Garzik :
  o Fix alpha build
  o Minimal initramfs support (based on Al Viro's work)
  o Kill stupid bug in initramfs that prevented it from working

John Levon :
  o fix timer_pit.c warning
  o oprofile: tiny makefile tidy
  o fix sys_lookup_dcookie prototype
  o fix APIC errors on oprofile restore

John Stultz :
  o linux-2.5.45_notsc-warning_A0

Jun Nakajima :
  o fixes for building kernel 2.5.45 using Intel compiler

Linus Torvalds :
  o Needs  for "in_atomic()" test
  o Add a "cmd_len" parameter to the request, so that device drivers
    don't have to try to figure it out for themselves.
  o Remove last vestiges of ide-cd.c "struct packet_command". It's been
    empty for a while now, and nothing uses it.
  o Set command length for the START_STOP command
  o Missed  in CONFIG_SWAP changes
  o BK ignore kconfig and initramfs files
  o Make ide-cd.c use the request command length information
  o Move SCSI command size information into , where the
    commands themselves already are.
  o Fix mbcache config dependency: if either EXT2 or EXT3 is
    compiled-in, mbcache should be too. 
  o Make presense of old/style EH routines cause warnings, not a
    compile failure.

  o Fix compile warning in slab.c

Luca Barbieri :
  o Clear TLS on execve

Maksim Krasnyanskiy :
  o Initialize hw broadcast so that BNEP multicast filter can be
    properly initialized.
  o Cleanup Bluetooth kernel messages
  o Bluetooth HCI UART driver fixes
  o Improved support for /proc/bluetooth

Manfred Spraul :
  o complete the move of the LDT code into

Marcel Holtmann :
  o Don't use typedefs for non opaque HCI objects
  o Module description cleanup

Matthew Dharm :
  o test for media-change like "popular" OSes

Matthew Wilcox :
  o HPUX emulation updates
  o Allocate a personality for HPUX
  o drivers/parisc
  o binfmt_som
  o fix rd.c compilation
  o PA-RISC updates
  o parport_gsc
  o remove *_segments() dummy functions from all other architectures

Patrick Mochel :
  o driver model: convert devices to use kobjects and sysfs
  o driver model: convert bus drivers to use kobjects and sysfs
  o driver model: convert drivers to use kobject and sysfs
  o driver model: convert device classes to use struct kobject and
    sysfs
  o driver model: convert interfaces to use kobject and sysfs
  o driver model: remove remaining driverfs glue
  o convert block devices and partitions to use kobject & sysfs
  o convert do_mounts.c to use sysfs instead of driverfs
  o create firmware subsystem and register it on startup
  o acpi: convert to use kobjects and sysfs
  o make sure block device_init() is called before part_init()
  o driver model: remove few remaining references to driverfs
  o convert edd to use kobjects and sysfs
  o driverfs: die die die
  o turn off kobject debugging by default
  o kobject: don't create directory for kobject/subsystem if name is
    NULL

Richard Henderson :
  o Fix fallout from oprofile patches
  o Save and restore CIA window configuration data
  o New file to debug clobbers of "current"
  o Fix up Alpha for initramfs changes
  o Misc Alpha compilation fixes
  o Don't clear pcb.unique if CLONE_SETTLS is not set
  o Fill in siginfo_t
  o Update clone syscall for TID and TLS arguments

Robert Love :
  o hyper-threading info in /proc/cpuinfo
  o decoded wchan in /proc
  o fix UP proc.c compile warning

Roman Zippel :
  o check QT only if needed

Russell King :
  o [ARM] Fix init section naming 2.5.44 changed .text.init to
    .init.text (and other similar section names).  This cset fixes the
    ARM parts to work with the new names.
  o [ARM] Fix ARM IRQ probe code
  o [ARM] Fix another usage of the now defunct 'tick'
  o [ARM] Add kallsyms support for ARM This cset adds support for
    kallsyms for the ARM kernel, and ensures that we have a reliable
    function prolog for backtracing.
  o [ARM] Only decend into mach-* if $(MACHINE) is defined
  o [ARM] Fix up some ARM PCI handling
  o [ARM] Make ARMv5 architecture select ARMv4 rather than ARMv3 IO
  o [ARM] Miscellaneous fixes
  o [ARM] Re-work L1 pagetable bit handling
  o [ARM] Replace __backtrace() with dump_stack()
  o [ARM] 2.5.45 updates
  o [SERIAL] Rename uart_event() to uart_write_wakeup() uart_event()
    only has one purpose, which is to wake up any pending writers via
    the line discipline.  Rename it to reflect its real functionality,
    and drop EVT_WRITE_WAKEUP.
  o [SERIAL] Remove struct pci_board from init_fn Traditionally, we
    allocated the private array of port parameters based on the
    detected board->num_ports, and then called the init_fn with the
    board pointer (which points into the global table.)  Some init_fn
    implementations modify num_ports, which therefore affects the
    global table.  Unfortunately, this means that if the init_fn
    increases num_ports (because we have two almost identical cards,
    the first with a smaller number of ports than the second), we will
    overwrite memory which hasn't been allocated to us.
  o [SERIAL] Fix two incorrect uses of __FUNCTION__
  o [SERIAL] Fix up 8250 IRQ chain handling
  o [SERIAL] Fix up formatting of serial names The tty layer's tty_name
    requires formatting codes in driver->name for the devfs and
    non-devfs cases.
  o [SERIAL] Make ALPHA_KLUDGE_MCR more generic for bluetooth modems,
    etc In addition to the Alpha OUT1/OUT2 kludge, devices like
    Bluetooth modems connected to serial ports make use of the modem
    control lines in non-standard ways.  Therefore, we implement a more
    flexible way to allow the modem control outputs to be forced to
    particular values irrespective of the normal usage of these
    signals.
  o [SERIAL] Tidy up 8250 port type detection The original port
    detection code was one large function with many tests without any
    clear structure.
  o [SERIAL] Fix build errors and warnings
  o [SERIAL] Set port->type to unknown only when using autoconfig
  o [SERIAL] [PARISC] add support for GSC serial Add discovery for
    PA-RISC 16550 serial ports.
  o [ARM] Fix various build errors in bk-cur
  o [ARM PATCH] 1300/1: more efficient irq number retrieval for PXA due
    to ARMv5 instructions
  o [ARM PATCH] 1301/1: detection of more XScale chips Adds detection
    of:
  o [ARM PATCH] 1312/1: BadgePAD 4 mach-sa1100 update
  o [ARM PATCH] 1310/1: Make SA-1100 IR compile
  o [ARM PATCH] 1298/1: display various PXA250 clocks on boot for
    better bug diagnosis Since it's easy to overclock that chip we'd
    better know why some board is  crashing randomly due to signal
    integrity problems.
  o [ARM PATCH] 1299/1: display various PXA250 clocks (part 2) Patch
    #1298/1 will be much more useful if the code is actually called.

Sam Ravnborg :
  o kbuild: Compatible with old bash, fix help, make clean fix
  o docbook: *docs targets fixed, clean ok for html
  o aic7xxx: Simplified cleaning, fixed firmware build

Steve French :
  o Fix locking of global smb list.  Add missing rc checks
  o Merge fixes from version 0.58 of cifs vfs

Theodore Ts'o :
  o Fixup Orlov block allocator for ext2
  o Orlov block allocator for ext3
  o Default mount options from superblock for ext2/3 filesystems
  o Ext2/3 forward compatibility: on-line resizing
  o Ext2/3 forward compatibility: inode size
  o Port of the 0.8.50 xattr-mbcache patch to 2.5.  (Shrinker API, hch
    cleanups) (now uses struct block_device * to index devices, and
    uses hash.h for hash function)
  o Port of (bugfixed) 0.8.50 xattr-ext3 to 2.5 (w/ hch cleanups.
    mbcache API)
  o Port of (bugfixed) 0.8.50 xattr-ext2 to 2.5 (w/ hch cleanups.
    mbcache API)
  o Port of 0.8.50 acl patch to 2.5
  o Port of 0.8.50 acl-ms-posixacl patch to 2.5
  o Port 0.8.50 acl-xattr patch to 2.5 (harmonize header file with
    SGI/XFS)
  o Port of (bugfixed) 0.8.50 acl-ext3 to 2.5
  o Port of (bugfixed) 0.8.50 acl-ext2 to 2.5

Trond Myklebust :
  o another kmap imbalance in 2.4.x/2.5.x RPC

Intel cc build fixes

on
November 4, 2002 - 8:35pm

Something I forgot to mention - this version also includes some fixes that should allow it to be compiled with the Intel C Compiler instead of gcc.

--
schnee

pre kernels

Anonymous
on
November 4, 2002 - 9:54pm

last time I have been very content with the pre kernels to 2.4.

what are pre kernels anyway? will the numbering scheme switch soon to linux-2.6pre or are the kernels still for a long time in the 2.5.xx numbering scheme (e.g. bad).

Re: pre kernels

on
November 5, 2002 - 2:32pm


last time I have been very content with the pre kernels to 2.4.

what are pre kernels anyway? will the numbering scheme switch soon to linux-2.6pre or are the kernels still for a long time in the 2.5.xx numbering scheme (e.g. bad).

-pre kernels are versions of the final release that are made available for testing purposes. Apart from that, if you run a production system, sticking with the current 2.4 kernel is probably the safest bet; the 2.5 branch, right now, is mostly of interested to those who want to give the new features a try, help with finding (and fixing) bugs etc.

It has just been frozen for major new features a few days ago, too, and, as mentioned in the story, Linus has stated that it will only be in the second quarter of 2003 that the first final 2.6 version can be expected. 2.6-test versions will probably surface earlier than that, but I personally don't think it will be until spring that we see these.

--
schnee

pre-kernel or not pre-kernel.

on
November 5, 2002 - 3:48pm

pre-kernel or not pre-kernel... compilation still fails... :)
--
I don't believe in fate...

They won't work with the current intel compiler

on
November 5, 2002 - 10:01pm

2.5.46 fixes compilation errors with the yet-to-be-released icc 7.0; it'll fail to compile with icc 6.0 (the current release), unless you change a whole lot of other stuff (CFLAGS, etc.)

Benchmarks?

Anonymous
on
November 7, 2002 - 3:52pm

Has anyone done any benchmarks on similar kernels compiled with different compilers?

gcc vs intel c

Anonymous
on
November 4, 2002 - 9:55pm

I would like to see benchmarks gcc vs intel c for the kernel.

i hear intel compiler is doin

Anonymous
on
November 5, 2002 - 11:10am

i hear intel compiler is doing very bad for non-intel x86s anyway (eg athlon).

Re: GCC vs ICC

Anonymous
on
November 5, 2002 - 12:29pm

ICC intentionally disables some optimizations for Athlon CPUs.

re:intel compiler doing that

Anonymous
on
November 5, 2002 - 12:29pm

Well that's to be expected. Your not going to develop a compiler that produces code that runs better on your rivals x86 family of processors then on your own ;)

Doubtful

on
November 5, 2002 - 4:54pm

Every ICC benchmark I've seen by third parties has shown ICC whalloping GCC, be it on a Pentium or Athlon. Most of the big advantages that ICC has over GCC are not specific to later Pentium chips, but are instead patented optimization techniques that GCC cannot implement, and therefore benefit Athlon processors just as much. This was prior to GCC 3.2, of course, so if there are any more recent benchmarks I'd be happy to see them.

Doubtful?

Anonymous
on
November 6, 2002 - 2:16am

I would bet that you have seen some very old benchmarks then. There were some corner cases which severely pessimized some optimization techniques in gcc 3.0 versus icc 5.x that I recall - but since 3.1, gcc has been very competitive, even besting icc in a couple of important C++ tests. Also, as I recall there is one person out there, whose name I can't recall - that uncovered a severe problem with ICC 5 when comparing it to GCC 3.0.x awhile back where GCC was about 5x faster for one of his genetic algorithms.

However, ICC still does outperform just about anybody for some specific tests which are primarily useful for scientific and multimedia applications (probably due mainly as the result of a lot of hand-tuning). There were a couple of patented techniques (graph coloring algorithms) used in commercial compilers that GCC has worked around, but the current one in 3.2 is still very good.

On the bright side, I read over on the gcc page that the FSF has recently persuaded the patent holders (IBM and Rice Univ.) to allow GCC to use them, which allowed the GCC folks to implement a new register allocator which is now on the mainline branch (available as a compile-time option) that will appear (I think) in 3.3.

I've also heard it from down the grape vine that ICC 7 is supposed to come out pretty soon now, so it would make an interesting comparison to the upcoming 3.2.1 (and later 3.3).

Personally my only major gripe as a user is that GCC has such horrible compilation speed. As a developer, GCC being written in C is a huge turnoff - I wouldn't want to touch it. Even C++ would be much better, and a lisp dialect or Haskell would be even sweeter. (I'd be really curious to know what langs/tools other compilers use).

GCC written in C is a turnoff?

on
November 6, 2002 - 5:14am

I was breathing a sigh of relief as I read your post. I too remember
a benchmark of GCC, ICC and another compiler, "KAI" I think it was
called. GCC (3.2) won most of the tests, ICC won the floating point
arithmetic tests ...and KAI won little or none.

3.0 was a major rewrite of many core parts, to make the code
easier to work with.
3.1 implemented some of the optimisations that could now be easily
added to this new code base.
3.2 is 3.1 with some standards compliant changes to G++
3.3 contains many new optimisations that were excluded from 3.2 for
reliability reasons.

3.2 is the recommended "for building operating systems" release.
Linux, the Hurd and most applications should (& will) use 3.2 even
after 3.3 is released. 3.4 or 3.5 will probably take over as the
"for building operating systems" release when they come out.

Back to the point (or the title at least):
> As a developer, GCC being written in C is a huge turnoff

Compilation speed may be an issue to once-off GCC compilers like
yourself but it isn't a problem for the developers because 'make'
will only recompile the files they have changed (and the few that
depend on them).

GCC in any other language would just be dog slow (for everyone).

Re: GCC written in C is a turnoff?

Anonymous
on
November 6, 2002 - 5:49am

Not sure what you're getting at with the compilation speed comment. In a typical full work day programming, the productivity decrease that results after hundreds of compiles really adds up. If you've ever used Delphi and hit an F-key to compile something and it happened so fast you didn't even realize it, you'll know just how important it can be. :) (Not that I'm trying to be a language advocate here - but it's a specific example of a language that can be parsed with a simple recursive-descent parser in one pass)

And for Q&A when you need to do automated testing, requiring total rebuilds of millions of lines of code - it can and easily often determines whether or not you can even use the compiler if the time is too long.

After I posted awhile ago I strolled through the gcc lists and heard that Apple has made GCC compilation speed a huge priority. Hope some big improvements come out of that. A standard, precompiled headers implementation would definately have a big immediate effect.

As for the subject, my personal opinion is that C isn't an appropriate language for such a problem domain these days. It has a huge amount of inertia though, and has become something of a least-common-denominator imo - which could be more beneficial than using a different language that isn't as widely understood from a pragmatic standpoint, but isn't as interesting from an aesthetic perspective. :)

compilation speed

on
November 6, 2002 - 3:22pm

> Not sure what you're getting at with the compilation speed comment.

I'm saying that compiling GCC is something that is done by probably a
few hundred people. Maybe one hundred compile GCC every day.
These hundred people don't have to compile the whole source tree, the
build system ensures that only the files that have changed since the
last compile get recompiled.

The time it takes to compile GCC is a cost. You say it's a high cost.

The benefits of using C are:

Speed: C produce the fastest executables of any high-level language.
Writing GCC in another language would increase the compilation time
of every other C/C++ project that uses GCC. Taking the cost away from
one hundred people and dumping it on millions of people would be pretty
selfish :p

Developers: C is the most widly known language (in GNU & Unix circles
anyway), this opens GCC to many developers. This leads to more
optimisations, which leads to a faster GCC which leads to making you
a bit happier.

I don't agree that C is a least-common-denominator, C can produce
the same executables as any other langauge can, it all depends on the
libraries you use. The difference is that C doesn't add functionality
to the language, it keeps it modular by pushing functionality out to
the libraries. There is nothing C++ can do that C can't do, remember
that C++ "compilers" used to work by translating C++ into C before
compilation. In this way, you can think of C++ as a restricted C.

Re: compilation speed

Anonymous
on
November 6, 2002 - 6:56pm

With the compilation speed comment I was referring to the time it takes GCC to build a program, not to build GCC. If you have a look at the cache locality behavior of gcc, you'll notice it is consistent with the runtime of a database - that points strongly to a big problem.

"C produce the fastest executables of any high-level language."

This comment is especially misguided. There are well known design flaws with C that make it difficult to optimize for, inparticular with alias analysis. For this reason inparticular, the "restrict" keyword was added to C99.

"I don't agree that C is a least-common-denominator"

There are C compilers for such a wide variety of platforms, that I would qualify it as a "least common denominator." That is at least what makes it compelling for many people to target.

Also interesting that of three choices you chose to single out C++.

As for the person who replied:

"And clearly you haven't touched it."

I have worked with GCC extensively for years and have dove into its internals. I'm also well aware of historical reasons for why GCC uses C - it made sense at the time.

if you've worked with a compiler you have no excuse...

Anonymous
on
November 7, 2002 - 5:36am

to claim that c++ is aesthetically pleasing.

The syntax is really ugly. Fortunately can you learn from the mistakes when you implement new languages...

I was working with gcc source on my train ride this morning. I've been hacking gcc for a few months. I'm very knowledgeable about compilers... But I do know what syntax looks like when I see it.

It sure can be, from a users

Anonymous
on
November 7, 2002 - 6:07am

It sure can be, from a users perspective. From the compiler writers perspective, creating a robust parser is very difficult. I don't think it is even possible to get some things like depedent names correct with traditional bison/yacc tools. I assume the latter is more what you're referring to.

it's the optimizations

on
November 6, 2002 - 6:05pm

The time it takes GCC to compile a program is almost certainly dominated by the optimizations it's doing. The time to parse and do other types of things like that are minimal. The thing is, the more opimizations you run, the longer the compilation takes, but the better the code you get out of it. It's a classic trade-off.

Try compiling with just -O or even no optimizations at all for your daily builds. Then when you're stable, add the -O2 (or whatever) and recompile and test. This is typically what I do. The difference in compilation speed is quite noticable (espcially on my 366/Celeron :-).

I don't doubt that there is room for improvement in GCC's code, but the reality is that you are almost always going to have this trade off.

"written in c"

Anonymous
on
November 6, 2002 - 7:45am

>>As a developer, GCC being written in C is a huge turnoff - I wouldn't want to touch it.

And clearly you haven't touched it.

GCC was, of course, written in C because it was originally a C compiler and C++ was not around. The reason that C was better than other languages is because it was portable. And GCC is likewise portable out the ying and yang.

If you had looked at the source code for gcc you would realise immediately that GCC source is no ordinary code. It was designed to be compiled on every skanky piece of hardware software combination that the human mind can devise.

GCC is so blasted portable you can learn C and still have time to port it to your newest cpu before the competition has had time to even think about porting their fancy kneecap Haskell compiler.

Long-format changelog

on
November 5, 2002 - 5:43pm

For those interested, lwn.net has the long-format changelog for this release available; they also report that online resizing support for ext2/ext3 has went into this release.

--
schnee

Long Changelogs

on
November 7, 2002 - 5:19am

You can always get the long changelog at kernel.org

reiser v4

Anonymous
on
November 5, 2002 - 9:20pm

Any word on if reiser version 4 will be merged into 2.5 now that the patches are available? reiser version 4 sounds like a lot of fun...

I am very happy to see that extended attributes have made it in. Are XFS's extended attributes abilities being taken advantage of in 2.5 (yet? ever?)?

Thanks.

XFS ACLs

on
November 5, 2002 - 10:09pm
    Are XFS's extended attributes abilities being taken advantage of in 2.5 (yet? ever?)?

There is currently no XFS ACL support in 2.5. Christoph Hellwig's XFS patches were a "minimal" merge; some things in the XFS tree - such as XFS ACLs and dmapi - aren't in 2.5.

XFS ACLs

Anonymous
on
November 6, 2002 - 5:52pm

but extented attributes (as the prior question dealt with) for XFS are in the initial XFS-merge in 2.5.36, though.

XFS ACLs

Anonymous
on
November 7, 2002 - 11:41pm

XFS ACLs are in, I've updated my notes (http://verein.lst.de/~hch/xfs/status.txt) now.

P.S. sigh, I hate logging in..

Re: reiser v4

on
November 5, 2002 - 11:27pm

Any word on if reiser version 4 will be merged into 2.5 now that the patches are available? reiser version 4 sounds like a lot of fun...

Hans Reiser at least has always said that he was firmly intent on seeing Reiser4 being merged into 2.5, but I don't recall whether Linus has stated his position on this yet.

--
schnee

Reiser4

on
November 6, 2002 - 12:30am

I would expect it to go in, but not right away, if you want to try it out, get the mcp kernel patchset of wolk.sf.net. Although I was personally unable to compile the Reiser4 stuff.

Re: Reiser4

on
November 6, 2002 - 1:23am

I would expect it to go in, but not right away.

Probably - or, rather, hopefully. :)

--
schnee

Re: Re: Reiser4

on
November 6, 2002 - 9:10pm

I sure hope it goes in. Then it will be tested by a lot of people, and after a while I may even have the courage to use it ;) - It has been rewritten, so we get to find all the bugs all over again. It is supposed to be quite a bit faster than v3, so it may all be worth it in the end.

Reiser4 patches?

on
November 6, 2002 - 3:11pm

Where can I get said patches... I can't see them :(

*Please*, I'd love to know, those features described in the Reiser4 documents sound really funky! :)

Michael

Re: Reiser4 patches?

on
November 6, 2002 - 3:46pm

Where can I get said patches... I can't see them :(

The current snapshot can be found at http://namesys.com/snapshots/2002.11.05/; new patches will also be made available in the snapshot/ directory.

HTH. :)

--
schnee

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.